Choose how many severity levels you want and how fast each must be answered. Get a matrix with definitions, examples and response rules, ready to paste into your incident policy.
Runs entirely in your browser — nothing you enter here is sent to a server.
In the first minutes of an incident nobody has time to debate how serious it is. A severity matrix answers that in advance: it defines a small number of levels by customer impact and attaches to each one a response — who is paged, how fast, who is told, whether a postmortem follows. The person who spots the problem picks a level and the rest happens by rule.
The definitions have to be about impact, not cause. "Database is down" is a cause and might be a SEV1 or a non-event depending on failover. "Customers cannot log in" is impact, and anyone can judge it.
Fewer than three and everything is urgent. More than five and people argue about the boundary between SEV4 and SEV5 while the site is down.
Add two or three real incidents from your own history to each level. People match against examples far more reliably than against wording.
Downgrading an incident later costs nothing. Starting too low delays the response when it matters.
Severity describes the impact now. Priority is the order you fix things in. A low-severity bug affecting your largest customer may still be top priority.
Treat the generated table as a first draft. Replace the examples with your own, set response times you can actually meet with your rotation, and add thresholds where you can measure them — "more than 5% of requests failing" is easier to apply than "many customers". Then review it after the next few incidents: if people regularly hesitate between two levels, the definitions need work.
SEV1 is a critical incident — a full outage, data loss or a security breach affecting most customers — that needs an immediate all-hands response. SEV2 is a major problem with a core feature that affects many customers but leaves the product partly usable.
Three to five. Four is the most common: critical, high, medium and low. Add a fifth "informational" level only if you want to track near misses formally.
It depends on the organisation; both conventions exist. Lower numbers always mean more severe. Pick one scheme and use it everywhere, including in your alerting tools.
Whoever declares it, using the matrix. The incident commander can raise or lower it as more is learned. Speed matters more than getting the level exactly right at the start.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.