Skip to main content
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

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