Error monitoring is configured

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.

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: 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 })
  

  1. Sentry is the most common choice and has a generous free tier: npm install @sentry/nextjs then run npx @sentry/wizard@latest -i nextjs for automatic configuration.
  2. Sentry captures unhandled exceptions, API route errors, and can track performance. Configure source map uploading so stack traces show your original code rather than minified output.
  3. Set up alert rules in Sentry to notify you (email/Slack) when new errors occur.
  4. Ensure error monitoring is initialized early in your app's lifecycle — for Next.js, use instrumentation.ts for server-side initialization.
  5. After setup, trigger a test error to confirm captures are working before launch.