Production monitoring or alerting is configured with repo-visible evidence

SOC 2 CC7.2 requires the entity to monitor system components for anomalies indicative of malicious acts and errors, and availability monitoring is the same evidence an auditor pulls for A1.1: "show me what watches production and who gets paged" is a standard request in the incident-management section. AI-generated and vibe-coded apps fail this reliably because monitoring is an operations habit, not a code prompt: coding assistants scaffold the app, the deploy config, even a /api/health endpoint, but nothing ever watches that endpoint, so the first signal of an outage or an anomaly is a customer complaint. Detection time drives incident impact and, for a Type II report, an unmonitored production service means there is no anomaly-detection evidence to sample at all. One passing leg of this check is an evidence-pointer: dashboard-configured monitors (UptimeRobot, Better Stack, Vercel alerts set in the web UI) are invisible to a repo audit, so a committed ops doc naming the monitoring provider and what it watches counts as the evidence, which is exactly the artifact an auditor will ask for. Note the relationship to this audit's health-check-endpoint check: that check verifies the probe surface exists; this check verifies something is actually watching it.

Pick the cheapest leg that fits your stack. For a Vercel/Next.js app with a health endpoint, a scheduled GitHub Actions synthetic check is a 10-line commit at .github/workflows/uptime.yml:

on:
  schedule:
    - cron: '*/15 * * * *'
jobs:
  probe:
    runs-on: ubuntu-latest
    steps:
      - run: curl --fail --max-time 10 https://yourapp.com/api/health

A failing run emails the repo owners, which is a real (if minimal) alert path. Alternatives: an Upptime repo config (.upptimerc.yml with your production URLs), a Checkly config (checkly.config.ts plus __checks__/), Prometheus Alertmanager rules, or Terraform monitor/alarm resources (aws_cloudwatch_metric_alarm, google_monitoring_alert_policy, pagerduty_service). If your monitoring genuinely lives in a dashboard (UptimeRobot, Better Stack web UI), commit an ops note at docs/ops/monitoring.md naming the provider, the monitored URLs or metrics, and where alerts go: that committed note is the evidence a SOC 2 auditor asks for under CC7.2.