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.

Why Severity Classification Often Lags the Alert

Severity classification delay is a recognizable failure mode independent of any specific incident: when an on-call engineer has to weigh impact and urgency from scratch under time pressure, the natural instinct is to gather more information before committing to a label, and that instinct is exactly backward during the first few minutes of an incident. Partial-degradation scenarios are the most common trigger — a service returning errors for some but not all requests, a latency spike that hasn't yet crossed an alerting threshold, a dependency failure whose blast radius isn't obvious — because these don't map cleanly to a binary "up or down" judgment call, and the engineer ends up in an ambiguous middle ground, discussing the classification with colleagues in a thread instead of paging further help in. Every minute spent debating whether a situation counts as one severity or another is a minute the actual response hasn't started; escalation, external communication, and the response checklist tied to a given severity level all wait on the label being assigned first. A published matrix removes exactly this bottleneck, because the two inputs it needs — how bad is the impact, how fast does this need attention — are answerable immediately from what's already known, without deliberation, which turns the classification step from an open-ended discussion into a fixed lookup that produces the same answer no matter who's holding the pager.

Frequently Asked Questions