Error tracking service is configured in production

Without an error tracking service, production failures are invisible until users report them — often via churn, refund requests, or social media. NIST SP 800-53 SI-11 requires software fault handling that produces meaningful diagnostic output; console.error into a log file no one monitors does not meet that bar. ISO 25010 reliability.fault-tolerance depends on detection: you cannot respond to a fault you cannot observe. A free-tier Sentry account covers most production workloads and takes under 30 minutes to configure.

Integrate Sentry (free tier covers most projects) or an equivalent service. Configure both frontend and backend capture in the same setup.

// instrumentation.ts (Next.js) or app entry point
import * as Sentry from '@sentry/nextjs'

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1, // 10% performance tracing
})

Verify the integration by deliberately throwing a test error in development and confirming it appears in the Sentry dashboard within 60 seconds. Then configure at least one alert rule (error rate threshold or new-issue notification) before marking this check complete.

• ID: error-resilience.logging-observability.error-tracking-service

• Severity: medium

• What to look for: Count all error tracking integrations (Sentry, Bugsnag, Datadog, etc.). Enumerate which capture frontend vs. backend errors and whether they include source maps. Look for error tracking service configuration: Sentry, Bugsnag, Rollbar, Airbrake, New Relic, Datadog, or similar. Check for API keys, DSNs, or configuration code in your application setup.

• Pass criteria: An error tracking service is configured in production environment; unhandled exceptions and promise rejections are captured and visible in a dashboard accessible to the team. At least 1 error tracking service must be configured for both frontend and backend error capture.

• Fail criteria: No error tracking service configured, or configured but not accessible in a dashboard, or only configured in development/staging, not production.

• Skip (N/A) when: The application is a static site or library with no runtime errors.

• Report even on pass: Report the tracking setup: "Error tracking via [service] covers frontend and backend."

• Cross-reference: For source maps with error tracking, see source-maps-error-tracking. For alert thresholds, see alert-thresholds.

• Detail on fail: "No error tracking service configured. Unhandled errors in production will be invisible to the team" or "Sentry configured in development but not in production environment"

• Remediation: Set up a free or paid error tracking service. Sentry has a generous free tier:

  // app/layout.tsx — Sentry integration
  import * as Sentry from '@sentry/nextjs'
  Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 0.1 })
  

  // app.tsx or _app.tsx
  import * as Sentry from "@sentry/react"
  
  if (process.env.NODE_ENV === 'production') {
    Sentry.init({
      dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
      environment: process.env.NODE_ENV,
      tracesSampleRate: 0.1,
    })
  }