Error reporting service is configured

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.

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