> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Severity Classification

> Define incident severity levels that drive consistent response and escalation

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

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

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

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

<CardGroup cols={2}>
  <Card title="Incident policies" icon="book" href="/incidents/policies">
    Configure severity-based trigger rules.
  </Card>

  <Card title="Playbooks" icon="book-open" href="/learn/incidents/playbooks">
    Create response procedures by severity.
  </Card>
</CardGroup>