IncidentOps

WHAT IT IS. IncidentOps is the operational discipline of detecting, coordinating, communicating, and learning during unplanned interruptions — run as a system that exists before the incident, not a heroism contest during it. Its mechanics are borrowed from fire services and matured at scale by SRE organizations: pre-assigned roles (an incident commander who coordinates but does not debug, a communications lead, a scribe capturing the timeline), a severity taxonomy whose levels carry automatic activation criteria, a dedicated channel and status page, and a blameless postmortem process that assumes good people in failed systems. NIST SP 800-61 and Google's incident-management chapter (linked below) are the citable references. WHY IT EXISTS. During an outage, the scarce resource is not effort — it is coordination and accurate information. Without defined roles, five people debug the same symptom while nobody tells customers; without a severity scale with activation criteria, the org argues about how bad it is while it gets worse; without a captured timeline, the postmortem reconstructs fiction. The economic argument: every practice here shortens time-to-mitigate or prevents the repeat incident, and repeats are where incident cost actually compounds. WHEN TO USE IT. From the first customer. Before customers, rehearse — a team that has never run a practice incident will run its first real one badly, at the worst possible time. This is one of the few disciplines where game-day rehearsal is the primary training method, not a nice-to-have. WHO OWNS IT. The incident commander role rotates through the on-call roster — it is a role, not a job title, and the IC may be the most junior person willing to coordinate. Management owns the blameless culture for real: a postmortem that ends in blame buys one honest writeup, ever. The comms lead owns the customer-facing voice (status page, updates at promised intervals even when the update is "still investigating"). WHAT GOOD LOOKS LIKE. Time-to-acknowledge is minutes and measured. Severity is called from pre-agreed criteria ("any data loss = Sev-1, no debate") and the call escalates DOWN freely — overcalling is cheap, undercalling is the disaster. Customers hear from you before they tell you. The timeline writes itself because the scribe captured it live. Postmortems publish blamelessly, action items have owners and due dates, and the closure rate is tracked — an incident process whose actions never close is theater with a template. Repeat-incident rate falls quarter over quarter; that is the outcome metric. HOW TO IMPLEMENT. Write the one-page severity scale with activation criteria and the IC role card (what the IC does, what they explicitly do not do). Stand up the incident channel convention and a status page — even a manual one. Run one rehearsal on a game day: break something in staging, run the full process, including the customer comms draft. Then hold the first real postmortem to that standard. NIST's handling guide maps cleanly onto these steps if you need the citable version. HOW TO ASSESS YOURSELF. The production readiness assessment scores on-call sustainability, runbook coverage, and incident learning loops: /assess. The maturity ladder below runs from improvisation (L1) to a practiced system with tracked closure and falling repeat rates (L5). Related: /observability-engineering is the detection layer, /sre surrounds incidents with SLOs and budgets, /resilience-engineering rehearses the failures before customers do.