A common severity framework
| Level | Name | Definition | Response |
|---|---|---|---|
| SEV-1 | Critical | Complete service outage affecting all users | All hands, immediate response, exec communication |
| SEV-2 | Major | Significant degradation or partial outage | On-call team responds within 15 minutes |
| SEV-3 | Minor | Limited impact, workaround available | Addressed during business hours |
| SEV-4 | Low | Cosmetic or non-user-facing issue | Added to backlog |
How to classify
Ask these questions during triage:- How many users are affected? — all, a segment, or a few?
- What’s the user impact? — can’t use the product, degraded experience, or cosmetic?
- Is there a workaround? — can users accomplish their goal another way?
- What’s the business impact? — revenue loss, reputational damage, compliance risk?
What severity drives
| Aspect | SEV-1 | SEV-2 | SEV-3 | SEV-4 |
|---|---|---|---|---|
| Response time | < 5 min | < 15 min | < 4 hours | Next sprint |
| Communication | Status page + exec | Status page | Internal only | Ticket |
| Escalation | Immediate | After 30 min | After 24 hours | None |
| Postmortem | Required | Required | Optional | None |
Tips for effective severity levels
Keep it simple
3–4 levels is enough. More levels create confusion: “Is this a SEV-2.5?”Define with examples
Abstract definitions lead to debates during incidents. Include concrete examples:- SEV-1: “Payment processing is completely down for all users”
- SEV-2: “API response times are 10x normal, causing timeouts for 30% of requests”
- SEV-3: “Dashboard shows stale data but API returns fresh data”
Allow severity changes
Initial triage may be wrong. Make it easy to escalate or de-escalate:- “We thought this was SEV-3, but it’s actually affecting more users → upgrade to SEV-2”
- “The blast radius was smaller than expected → downgrade to SEV-3”
Avoid severity inflation
If everything is SEV-1, nothing is. Reserve critical severity for genuine emergencies. Teams that over-classify lose credibility.Mapping to DevHelm
DevHelm uses these incident severities:| DevHelm severity | Typical mapping |
|---|---|
DOWN | SEV-1 / SEV-2 — service is not responding |
DEGRADED | SEV-2 / SEV-3 — service is slow or partially broken |
MAINTENANCE | Planned — scheduled downtime |
Incident policies
Configure severity-based trigger rules.
Playbooks
Create response procedures by severity.