Skip to main content
Severity levels standardize how your team responds to incidents. Clear definitions reduce confusion and speed up decision-making during triage.

​
A common severity framework

​
How to classify

Ask these questions during triage:
  1. How many users are affected? — all, a segment, or a few?
  2. What’s the user impact? — can’t use the product, degraded experience, or cosmetic?
  3. Is there a workaround? — can users accomplish their goal another way?
  4. What’s the business impact? — revenue loss, reputational damage, compliance risk?

​
What severity drives

​
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:

Incident policies

Configure severity-based trigger rules.

Playbooks

Create response procedures by severity.