Incident Management

When the firehose lights up or a customer reports an outage, this is where the response happens. The active incident list shows severity (SEV1/2/3/4), affected tenants, responder, started-at, and ETA to resolution. Create-incident captures severity, affected services, affected tenants, and an initial summary, and pages on-call through PagerDuty Events API v2 or OpsGenie Alerts API v2 with `dedup_key = sys-incident:<id>` so a single incident never wakes anyone twice.

The timeline at `POST /sys/incidents/{id}/updates` writes append-only `SysIncidentUpdateEntry` rows with author, status transitions, and a comms-sent summary so investigators can reconstruct the response without reading Slack. Public status-page sync flips visibility through `POST /sys/incidents/{id}/public`; `GET /public/status/active` returns a customer-safe projection for `status.petanque.life`, cached 60 seconds so the status page never hammers the API. Post-mortem links are external (Notion, Confluence, Google Docs) — the console intentionally does not host the doc, just records the URL so the audit trail can prove the post-mortem exists.

The affected-users endpoint scans `ApiUsageEvent` for the outage window and returns the unique user count by tenant, so an operator can answer `how many people did this hit` with real data rather than a guess. The SLA impact report emits one credit row per affected tenant against a 99.9 percent target with credit tiers at 0 / 10 / 25 / 50 percent for outage durations of 0 / 45 / 240 / 720 minutes; the rows feed the F21.07 billing flow so credits land on the next invoice without manual arithmetic. Every action is audited and the incident also ties back to the dashboard system map and firehose for deep links during response.