Two teams can run the same architecture and have wildly different outages, because the architecture determines what fails and the response determines how long it hurts. A well-drilled team turns a control-plane wobble into a fifteen-minute blip; an ad hoc team turns the same event into a three-hour saga of people talking over each other in a chat channel. This model grades the part that architecture diagrams never show: how an organization actually behaves when the pager goes off.
The five levels
Response maturity spans four practices that improve at different rates: detection (how you find out), coordination (how you run the response), on-call (whether it is sustainable), and learning (whether it changes anything). Each level below assumes the practices before it.
| Level | Coordination | On-call health | Learning loop |
|---|---|---|---|
| 1 Ad hoc | Whoever notices, fixes | No rotation, hero-driven | None |
| 2 Reactive | A channel, no clear lead | Rotation exists, high toil | Informal chat recap |
| 3 Defined | Named incident commander | Sustainable load, runbooks | Written post-mortems |
| 4 Managed | Roles split (command, comms, ops) | Toil budget, error-budget-aware | Actions tracked to done |
| 5 Self-improving | Roles are second nature | Load actively engineered down | Reviews change the system |
Level 1 - Ad hoc
Incidents are handled by whoever happens to see them, usually the same one or two people every time. There is no rotation, no defined severity, and no record afterward. The team survives on the heroics of its most senior engineers, which feels fine until those people burn out or leave. Most early-stage teams live here, and the risk is that success arrives before the practice does.
Level 2 - Reactive
A rotation exists and incidents get a chat channel, but nobody is clearly in charge, so the response is a scrum: several people debugging in parallel, duplicate work, and a customer update that goes out late or not at all. On-call toil is high and unmeasured. After the incident there is a recap in chat that no one revisits. This is a common level, and it is exhausting.
Level 3 - Defined
The response has a named incident commander who coordinates rather than fixes. Severity is classified consistently (using something like the severity framework), runbooks exist for the common failure classes, and every qualifying incident produces a written post-mortem. On-call load is deliberately kept sustainable. The organization can now describe what happened in a form that compares across incidents.
Level 4 - Managed
The Google SRE roles are fully split: an incident commander decides, a communications lead handles stakeholders and customers, and operations responders remediate. Post-mortem actions are tracked to completion, not just written. On-call has a toil budget and the team watches its error budget (see the SLO framework) so response and engineering are informed by the same numbers. Reliability has an owner and a rhythm.
Why splitting command from remediation matters
The largest single jump in effectiveness is separating the person who runs the response from the person who fixes the problem. When they are the same human, coordination and communication silently lose to firefighting, so stakeholders go dark and parallel efforts collide. A commander who owns the timeline and hands off the keyboard is the difference between a controlled response and a scrum.
Level 5 - Self-improving
Roles are second nature, so the meta-work vanishes and the team focuses on the problem. On-call load is actively engineered downward: recurring pages become automation, and the toil trend is a metric a leader watches. Reviews do not just record; they change the system, closing the classes of incident that used to recur. Few organizations sustain Level 5 everywhere, and none reach it without the lower rungs first.
Using the model
Grade each of the four practices independently; your real maturity is the lowest, because that is where the next bad night finds you. The cheapest large win for most teams is at the coordination step (naming an incident commander and splitting comms from ops costs process, not infrastructure). Pair this with the reliability maturity model so your architecture and your response mature together, and remember that a mature review closes the loop on money too: qualifying incidents that breach an SLA should leave the post-mortem as a filed claim. Our research on outage duration, the incident data, the corpus methodology, and the credit mechanics at cloudslacredit.com, cloud-credits.com, and awsdown.com all feed the credit gap that a Level 4 review would have closed.
Response maturity is culture made procedural. Our monitoring sponsor, Next Signal, watches provider status feeds so your response starts from an alert and an evidence trail rather than from a customer complaint and a blank page.