Without error monitoring, production failures are invisible until a user emails you to complain — typically hours after the error first occurred. NIST SP 800-53 SI-11 (Error Handling) and NIST CSF 2.0 DE.CM (Continuous Monitoring) both establish error detection as a baseline operational control. Vibe-coded projects frequently ship with no monitoring configured because the development workflow never required it — but in production, unhandled exceptions in API routes, third-party SDK failures, and database connection errors all produce silent 500s that drain user trust with no signal to the developer.
High because the absence of error monitoring means every production failure — unhandled exceptions, API errors, database outages — is invisible until users report it, delaying response by hours.
Install an error monitoring SDK and initialize it early in the application lifecycle. Sentry is the most common choice with a generous free tier.
npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs
The wizard configures sentry.client.config.ts, sentry.server.config.ts, and instrumentation.ts automatically. Set up a Sentry alert rule to notify you on new errors via email or Slack. Enable source map uploading so stack traces reference your original code, not minified output. After setup, trigger a deliberate test error to confirm captures are reaching your Sentry project before launch.
ID: pre-launch.monitoring.error-monitoring
Severity: high
What to look for: Count all error monitoring integrations (Sentry, Bugsnag, Datadog, etc.). Enumerate which capture frontend vs. backend errors. Check dependencies for error monitoring libraries: @sentry/nextjs, @sentry/react, @sentry/node, bugsnag, rollbar, datadog, honeybadger, raygun, trackjs. Check for Sentry configuration files (sentry.client.config.ts, sentry.server.config.ts, sentry.edge.config.ts, sentry.config.ts). Check for error monitoring initialization in _app.tsx, layout.tsx, instrumentation.ts, or middleware. Check for error capture calls in API routes and error boundaries.
Pass criteria: An error monitoring service is initialized in the project and configured to capture both client-side and server-side errors. At least 1 error monitoring service must be configured for production.
Fail criteria: No error monitoring library found in dependencies or configuration.
Skip (N/A) when: Never for production web applications — knowing when your app is broken is fundamental.
Report even on pass: Report the monitoring service found: "Error monitoring configured with [service name]."
Cross-reference: For uptime monitoring, see uptime-monitoring. For custom error pages, see custom-500.
Detail on fail: "No error monitoring library detected — production errors will be silent and you will only learn about failures from user reports"
Remediation: Without error monitoring, you're flying blind. Real users will hit errors you never see in development:
// app/layout.tsx — Sentry initialization
import * as Sentry from '@sentry/nextjs'
Sentry.init({ dsn: process.env.SENTRY_DSN })
npm install @sentry/nextjs then run npx @sentry/wizard@latest -i nextjs for automatic configuration.instrumentation.ts for server-side initialization.