An error-tracking SDK is installed and actually initialized in code, with server-side coverage

SOC 2 CC7.2 requires that you monitor system components for anomalies, and the first question an auditor asks is "how do you know when production breaks?" An error-tracking service (Sentry, Bugsnag, Rollbar, Honeybadger) that aggregates exceptions and alerts a human is the standard code-level answer; console.error scrolling past in a log nobody tails is not. AI-generated apps fail this in a specific, repeatable way: the model adds @sentry/nextjs to package.json because the prompt mentioned "production ready", then never runs the wizard, so there is no sentry.server.config.ts, no instrumentation.ts register, and no DSN wiring. The dependency line looks like monitoring; unhandled server exceptions still vanish silently. Client-only inits are the second failure mode: browser errors get captured while the API routes that actually corrupt data report nothing. This check verifies the wiring in the repo (an init call with a DSN sourced from env, on the server side), which is exactly the code evidence a SOC 2 auditor will trace when testing CC7.2.

Run npx @sentry/wizard@latest -i nextjs (or install @sentry/node for Express) and commit the generated config: sentry.server.config.ts plus an instrumentation.ts whose register() imports it, with Sentry.init({ dsn: process.env.SENTRY_DSN }) reading the DSN from an environment variable, never a hardcoded string. For Express, call Sentry.init at the top of your server entry (src/server.ts) and add Sentry.setupExpressErrorHandler(app) so unhandled route exceptions are captured. Verify the init file is actually imported by the app entry path, not just sitting in the repo. Structured logging (pino, winston) is complementary but is not a substitute: the saas-logging audit covers that layer.

• ID: error-tracking-initialized
• Severity: high
• What to look for: First determine whether this is a deployable app: a web/server framework in package.json (next, express, fastify, koa, hono, remix, @sveltejs/kit, nuxt), or requirements.txt/pyproject.toml with django/flask/fastapi, or a Go main package serving HTTP. If it is a library, CLI, or static-only site with no server code, skip. Otherwise enumerate: (a) an error-TRACKING dependency in package.json: @sentry/nextjs, @sentry/node, @sentry/remix, @sentry/sveltekit, @bugsnag/js, @bugsnag/node, rollbar, @honeybadger-io/js, @highlight-run/node, @highlight-run/next (Python: sentry-sdk, bugsnag, rollbar; Go: github.com/getsentry/sentry-go); and (b) a real init call in code: Sentry.init( in sentry.server.config.{ts,js}, sentry.edge.config.{ts,js}, or instrumentation.{ts,js} with a register() that imports the server config, or Sentry.init( / Bugsnag.start( / new Rollbar( / Honeybadger.configure( in a server entry (src/server.ts, src/index.ts, app.ts, main.py, main.go) with the DSN/API key read from env (process.env.*, os.environ, os.Getenv); and (c) server-side coverage: the init must exist in a server-executed file, not only sentry.client.config.ts or a 'use client' component. Quote the actual dependency line and init call as you find them. Distinguish error tracking (an aggregation and alerting service) from error logging: console.error, pino, winston, or morgan alone never satisfy this check.
• Pass criteria: Deployable app, tracking dependency present, AND an uncommented server-side init call whose DSN/API key comes from an environment variable, AND that init file is reachable from the app (Next.js convention files sentry.server.config.*/instrumentation.* count as reachable by convention; for Express-style apps the init must be imported or called in the actual server entry). Before marking pass, quote the init call and its file path; a pass without a quoted server-side init excerpt is invalid. Do NOT pass merely because the dependency name appears in package.json, in a lockfile, or in a README: vocabulary presence is not wiring.
• Fail criteria: Deployable app with no error-tracking dependency at all; OR dependency installed but no init call anywhere (the classic half-wired AI-slop state: package.json line only); OR init exists but is commented out, gated behind an always-false condition, or lives in a file nothing imports; OR init is client-only (sentry.client.config.ts or browser Bugsnag.start with no server config or instrumentation register); OR the "init" is a stub with an empty or placeholder DSN string (dsn: '', dsn: 'YOUR_DSN_HERE').
• Skip (N/A) when: Not a deployable app (library, CLI tool, or static site with no server runtime). Quote: "No server framework in package.json and no server entry point: not a deployable app, error tracking N/A".
• Before evaluating, quote: The dependency line from package.json (or its absence stated explicitly), plus the file path and a 1-3 line excerpt of the init call showing the DSN source. On the client-only fail variant, quote the client config path and state that no server config or instrumentation register was found.
• Report even on pass: "Error tracking: <sdk> init at <path>, DSN from <env var>, server-side: yes".
• Detail on fail: "@sentry/nextjs in package.json but no sentry.server.config.ts, no instrumentation.ts register, and no Sentry.init call anywhere: dependency installed, never wired" or "Sentry.init present only in sentry.client.config.ts; server routes under app/api/ have no error tracking: client-only coverage".
• Remediation: Run npx @sentry/wizard@latest -i nextjs and commit sentry.server.config.ts + instrumentation.ts with Sentry.init({ dsn: process.env.SENTRY_DSN }); for Express, init at the top of src/server.ts and add Sentry.setupExpressErrorHandler(app). Logging pipelines (pino/winston) are covered separately by the saas-logging audit and do not substitute for tracking.