Severity Definitions
Kesterline, field-service software, 6 on the on-call rota
| Written from | 10 incidents in the 12 months to 31 October |
| Indexed on | Symptoms visible at minute zero, not impact |
| Reclassification rate | 50%, which is why this is version 3 |
Each level carries the incidents that landed in it
| Level | What the responder can see at minute zero | Real incidents that landed here | If you cannot tell |
|---|---|---|---|
| SEV1 | Login, dispatch or card capture failing, not slow. Or writes failing while reads look fine. | 14 Mar auth out 51 min. 2 Jun card tokens rejected 22 min. 9 Sep failover stuck 68 min. | Call it SEV1 |
| SEV2 | One named feature failing, rest of the product fine. Or one account above 500 seats fully down. | 21 Jan invoice PDFs down 4 h. 8 Apr largest account locked out 37 min. | Call it SEV2, say so |
| SEV3 | Visibly wrong, fewer than 50 accounts, and support has a workaround to hand out. | 29 May export capped at 1000 rows. 12 Aug crash on one Android version. | No workaround means SEV2 |
| SEV4 | One report, nothing broken for anybody else, no revenue path affected. | 6 Mar a customer's own firewall blocking our webhooks. | No ambiguity here |
Why the incidents column is the whole sheet
Nobody woken by a pager compares the thing in front of them against a definition. They ask whether this is as bad as the last bad one. A level carrying three dated precedents answers that; four adjectives do not.
The 9 September entry is the reason SEV1 names a symptom rather than an impact. Reads were healthy, so the dashboard stayed green and it ran as a SEV2 for thirty-one minutes.