Without an error reporting service, production failures are invisible until a user files a complaint — and most users don't. CWE-778 (Insufficient Logging) classifies the absence of error capture as a reliability and observability failure. ISO 25010 reliability.fault-tolerance requires that faults be detected and recorded. Practically, this means bugs introduced in a deploy go undetected until support volume spikes, by which time the defect may have affected thousands of sessions. A DSN hardcoded in source rather than an environment variable adds a credential-exposure risk on top of the observability gap.
High because production errors with no monitoring service are invisible until user-reported, creating an unbounded failure detection lag.
Install and initialize an error reporting service. For Next.js, use the Sentry wizard for automatic configuration:
npx @sentry/wizard@latest -i nextjs
This creates sentry.client.config.ts, sentry.server.config.ts, and updates next.config.ts. Store the DSN in .env.local:
NEXT_PUBLIC_SENTRY_DSN=https://your-dsn@sentry.io/project-id
Verify by triggering a deliberate error in production mode and confirming it appears in your Sentry dashboard within 60 seconds. Never hardcode the DSN value directly in source — always read it from an environment variable.
ID: saas-error-handling.error-reporting.error-reporting-service
Severity: high
What to look for: Check package.json for error monitoring dependencies: @sentry/nextjs, @sentry/react, @sentry/node, @bugsnag/js, @bugsnag/plugin-react, @datadog/browser-logs, newrelic, rollbar, honeybadger-js, @highlight-run/next, highlight.run, or similar. If a dependency is found, verify it's actually initialized: look for Sentry.init(), Bugsnag.start(), or equivalent initialization calls in the app entry point, instrumentation file (instrumentation.ts for Next.js), or framework config. Check that the initialization references a DSN or API key via environment variable (e.g., SENTRY_DSN, NEXT_PUBLIC_SENTRY_DSN).
Pass criteria: List all error monitoring packages found in dependencies. Pass if a recognized error monitoring package is installed AND an initialization call is present with a DSN/API key referenced via environment variable (not hardcoded). For Next.js, also pass if sentry.client.config.ts / sentry.server.config.ts / sentry.edge.config.ts or instrumentation.ts contain valid Sentry init calls. Report even on pass: "Error monitoring configured via [package name] with environment-based DSN."
Fail criteria: Fail if no error monitoring package is present — at least 1 monitoring package required. Fail if a package is installed but no initialization call is found (dependency declared but never used). Fail if the DSN/API key is hardcoded in source rather than read from an environment variable. Example: "@sentry/nextjs in dependencies but no Sentry.init() call found"
Cross-reference: For client-side error reporting coverage, see the client-errors-reported check in this audit.
Skip (N/A) when: Never — error reporting is applicable to all production web applications regardless of framework or size.
Detail on fail: Specify whether the package is entirely absent, installed but not initialized, or initialized with a hardcoded credential (e.g., "No Sentry/Bugsnag/similar dependency in package.json" or "@sentry/nextjs installed but no Sentry.init() call found in instrumentation.ts or sentry.*.config.ts"). Max 500 chars.
Remediation: Without an error reporting service, production errors are invisible. You only learn about failures when users report them — and most users don't.
Sentry is the most common choice for Next.js. Install it with their wizard for automatic configuration:
npx @sentry/wizard@latest -i nextjs
This creates sentry.client.config.ts, sentry.server.config.ts, and updates next.config.ts automatically. Store your DSN in .env.local:
NEXT_PUBLIC_SENTRY_DSN=https://your-dsn@sentry.io/project-id
After setup, verify by triggering a deliberate error in production mode and confirming it appears in your Sentry dashboard within 60 seconds.
For the AuditBuffet Logging & Monitoring Audit, a deeper analysis of your observability stack — alerting thresholds, log retention, and uptime monitoring — is available separately.