Incident Severity Matrix

A Framework Borrowed, Not Invented

The impact-versus-urgency grid this tool implements didn't originate in software operations at all — it's a direct descendant of IT service management (ITSM) practice, most visibly formalized in ITIL's incident prioritization matrix, which has been classifying support tickets this way since long before "SRE" was a job title. What changed when web-scale engineering organisations adopted it is the vocabulary and the speed: ITIL's matrix was built for a help-desk ticket queue measured in hours or days, while an SRE team applies the identical two-axis logic to decisions that need to be made in the first ninety seconds after a page fires. The underlying idea survived the transplant because it solves the same problem in both settings — replacing an argument about severity with a lookup.

Sixteen Boxes Collapsed Into One Number

Underneath the interface, the tool is a lookup table with sixteen entries: four Business Impact levels (Critical, High, Medium, Low) crossed against four Urgency levels (Immediate, High, Medium, Low) produce exactly one severity outcome per combination, ranging from SEV1 down to SEV5. Selecting impact and urgency doesn't just return a label — each of the sixteen cells carries its own bundle of attributes: a time-to-acknowledge target, a time-to-resolve target, a communications cadence, the on-call scope that should be paged, an escalation chain, a response checklist, and a pre-filled communication template with placeholders ready to drop into Slack, a status page, or PagerDuty. The mechanism is deliberately simple — a matrix lookup rather than a scoring formula — because during a live incident, the last thing a responder needs is an algorithm to argue with.

A Matrix vs. Just Trusting Your Gut

The obvious alternative to a published matrix is letting whoever is on-call decide severity by feel, and most teams start out doing exactly that. It works fine until the moment it doesn't: two different engineers facing comparable outages will reach for different severities depending on how the last incident review went, how loud the reporting customer is, or how close it is to a release freeze. A matrix removes that variance by forcing the same two questions every time — how bad is the impact, how fast does this need attention — and mapping the answer deterministically, which means two engineers looking at the same facts land on the same severity even if they've never met. The trade-off is upfront cost: someone has to define what "Critical impact" actually means in concrete, measurable terms before the matrix is trustworthy, whereas gut-feel classification requires no setup at all until it quietly produces its first inconsistent, disputed severity call.

The Outage That Took Forty Minutes to Get a Name

A representative scenario: a checkout service starts returning errors for roughly 8% of requests during a regional traffic spike. The on-call engineer isn't sure whether this counts as a full outage — it isn't 100% down — so the incident sits un-declared for the first twenty minutes while people discuss severity in a thread instead of paging anyone else in. By the time someone finally calls it a SEV2, escalates, and pulls in a second engineer, the error rate has climbed to 30% and the delay itself becomes a line item in the post-mortem. Run the same facts through a published impact/urgency matrix at minute one — Medium-to-High impact, Immediate urgency — and the severity, the escalation path, and the communication template are all decided before the debate ever starts, which is the entire value proposition: the matrix isn't there to make incidents less severe, it's there to stop the classification argument from becoming part of the incident.

Frequently Asked Questions