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.