# Error monitoring is configured

- **Pattern:** `ab-002179` (`pre-launch.monitoring.error-monitoring`)
- **Severity:** high
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-002179
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-002179)

## Why it matters

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.

## Severity rationale

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.

## Remediation

Install an error monitoring SDK and initialize it early in the application lifecycle. Sentry is the most common choice with a generous free tier.

```bash
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.

## Detection

- **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:

  ```ts
  // 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.

## External references

- nist SI-11
- iso-25010 reliability.fault-tolerance
- nist-csf DE.CM

Taxons: observability

HTML version: https://auditbuffet.com/patterns/ab-002179