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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.