Error monitoring is configured
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.
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.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Pre-Launch Checklist Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- nist:rev5 · SI-11 — Error Handling
- iso-25010:2011 · reliability.fault-tolerance
- nist-csf:2.0 · DE.CM — Continuous Monitoring
Taxons
History
- 2026-04-18·v1.0.0·Initial import from pre-launch·automated