Incident severity classification
Assess impact and urgency to classify severity and route to the right on-call tier.
Incident severity classification is the gateway between chaos and order. Without it, a single customer complaint can wake the entire on-call rotation, or a data corruption bug can silently fester because nobody realized how bad it was. This template lays out the decision tree: report comes in, ask three questions (service down? major feature broken? revenue impact?), and route to the right team tier: all-hands war room, on-call manager, or async ticket.
The key insight is that classification happens before the incident commander takes over. It's the triage checkpoint that prevents alert fatigue and ensures critical incidents get the right eyeballs immediately.
When to use this template
- On-call playbook — print this diagram and hang it next to every on-call's desk. When an alert fires, follow the tree before declaring war room.
- Incident-response training — walk new hires through the classification criteria so they understand why some incidents page everyone and others become tickets.
- Post-incident review — if you classified wrong (downgraded something that should have been SEV-1, or paged everyone for a SEV-3), trace where the decision tree misfired and update your criteria.
How to adapt it
Customize the decision tree to your incident taxonomy and business model:
- Add data-loss detection as a direct SEV-1 branch if you handle sensitive data (payment info, PII).
- Insert a customer notification urgency branch (notify all in <15 min, some in <1 hour) after classification to drive your comms timeline.
- Add on-call escalation tiers (primary → manager → VP) based on SEV level if your org is large.
Visual edits regenerate clean Mermaid code, so you can extend and refine your decision criteria without rewriting syntax.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Incident reported] --> B[Is service down?]
B -->|Yes| C[Check customer count affected]
B -->|No| D{Major feature broken?}
C -->|All customers| E[SEV-1<br/>Page all on-call]
C -->|Subset| F{Revenue-critical?}
F -->|Yes| E
F -->|No| G[SEV-2<br/>Page primary on-call]
D -->|Yes| H{User-facing?}
D -->|No| I[Check data loss risk]
H -->|Yes| G
H -->|No| J[SEV-3<br/>Create incident ticket]
I -->|Data corrupted| K[Escalate to SEV-1]
I -->|No risk| J
K --> L[Declare war room]
E --> L
G --> M[Open #incident channel]
M --> N[Assign incident commander]
J --> O[Schedule team review]
Frequently asked questions
- What is incident severity classification?
- It's a decision tree that maps symptoms (is the service down? how many customers?) to severity levels (SEV-1, SEV-2, SEV-3), which in turn determine who gets paged and how fast. SEV-1 pages everyone immediately (all-hands outage), SEV-2 pages the primary on-call (subset impact), SEV-3 becomes a ticket (degradation, no customer impact).
- Why is revenue impact a classification criterion?
- Because not all downtime is equal. Five minutes of your checkout broken (revenue-critical) is worse than five minutes of the analytics dashboard (inconvenient but not a sale-killer). Severity classification forces the question: would this cost us money or customers? If yes, it's at least SEV-2.
- What is the difference between SEV-1 and SEV-2?
- SEV-1 is all-hands: the entire service is down, all customers are affected, or critical data is corrupting. Everyone gets woken. SEV-2 is scoped: a subset of customers is impacted, or a major feature is broken but workarounds exist. The primary on-call handles it; others stay on standby.
- How do I adapt this for my organization?
- Replace the customer-count thresholds (all vs subset) with your real numbers — maybe SEV-1 is >10% of ARR affected, SEV-2 is 1-10%. Add your revenue-critical services (checkout, auth, billing) as explicit branches. Change the page-out targets from 'all on-call' to your escalation chain (primary → secondary → manager). Visual edits regenerate clean code, so you can sketch your decision tree without touching Mermaid syntax.
Related templates
Disaster recovery plan
Detection, failover, validation, and restoration after service outage.
Customer incident lifecycle sequence
Communication flow from detection through acknowledgment, investigation, resolution, and closure.
Bug triage workflow
Classify, prioritize, and assign incoming bug reports systematically.