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

# Incident Severity vs Priority: What's the Difference?

> Severity measures how bad an incident's impact is; priority determines how urgently your team responds. They usually align — but not always.

Severity describes the impact of an incident — how badly it degrades service and how many users it affects. Priority describes the urgency of the response — how quickly your team should act relative to everything else in flight. Severity is an assessment of the world; priority is a decision about your resources. They correlate strongly, but a low-severity issue can still be high priority, and vice versa.

## Comparison at a glance

| Dimension    | Severity                                             | Priority                                    |
| ------------ | ---------------------------------------------------- | ------------------------------------------- |
| Answers      | "How bad is the impact?"                             | "How urgently do we act?"                   |
| Based on     | Scope of degradation, users affected, data risk      | Business context, deadlines, who's affected |
| Common scale | SEV1–SEV4 (or SEV0–SEV3)                             | P1–P4                                       |
| Set by       | Responder assessing the incident                     | Responder or leadership weighing trade-offs |
| Drives       | Escalation, paging, exec notification, comms cadence | Ordering of work and resource allocation    |
| Changes when | Impact grows or shrinks                              | Business context shifts                     |

## What is incident severity?

Severity classifies impact on a fixed scale so everyone responds consistently. A typical scheme:

* **SEV1** — critical: full outage or data loss risk; most users affected.
* **SEV2** — major: significant degradation or a core feature down for many users.
* **SEV3** — minor: partial degradation, workaround exists, limited user impact.
* **SEV4** — low: cosmetic issues or minor bugs with negligible impact.

Severity should be defined by observable criteria ("checkout error rate above 5%") rather than gut feel, because it triggers concrete machinery: who gets paged, whether executives are notified, how often status updates go out, and whether a retrospective is required.

## What is incident priority?

Priority ranks the response against everything else your team could be doing. It folds in context that severity deliberately ignores: contractual deadlines, which customer is affected, regulatory exposure, upcoming launches, and what else is on fire. Two incidents of identical severity can carry different priorities — one affects a trial user on a Sunday night, the other affects your largest customer during their peak sales event.

## Can a low-severity incident be high priority?

Yes, and this is exactly why the two dimensions exist separately. A typo in your pricing page is SEV4 by any impact rubric — nothing is down, no errors, no data at risk. But if it displays the wrong price and creates legal exposure, fixing it may be P1: drop other work and ship the correction now. Conversely, a SEV2 degradation in an internal batch system at 2 a.m. might be P3 — real impact, but nothing gained by waking anyone when it can be fixed at 9 a.m.

## Worked example

Two incidents open on the same afternoon:

1. **Incident A:** search indexing lags 45 minutes behind. Impact is broad but shallow — every user sees slightly stale results. The team classifies it **SEV3**. No SLA covers search freshness and no revenue path is blocked, so it's **P3**: fix within the sprint.
2. **Incident B:** a single enterprise customer can't export compliance reports. Only one tenant is affected, so it's **SEV3** by the impact rubric. But that customer's regulatory filing is due in 48 hours and the contract includes support commitments — the team sets **P1** and assigns an engineer immediately.

Same severity, opposite priorities. If the team had only one field to express both, they'd either inflate B's severity (breaking their paging and reporting rules) or under-respond to it.

## Should you track both fields?

Smaller teams often start with severity alone and treat it as an implicit priority — for a five-person startup where every SEV1 is all-hands anyway, that's fine. Add a separate priority field once you regularly have multiple concurrent incidents, customer-specific commitments, or a support queue feeding engineering. The test: if you find yourself arguing "it's technically SEV3 but we should treat it like a SEV1," you need a priority field.

## How this works in Rootly

Rootly ships with configurable severity levels that can drive escalations, notifications, and workflows automatically, and you can add a separate priority as a custom field. See [Severities](/configuration/severities).

## Related terms

* [MTTA vs MTTR](/glossary/mtta-vs-mttr)
* [SLA vs SLO vs SLI](/glossary/sla-vs-slo-vs-sli)
* [Incident vs Problem](/glossary/incident-vs-problem)
* Browse the full [Incident Management Glossary](/glossary)