severity vs priority: how support should use both

TL;DR

Severity measures how bad the damage is. Priority measures how fast the business wants it fixed. They are two different axes, and merging them into one number is where triage arguments start. Keep both, let different people set each one, and use the matrix below to decide what happens first.

The query

severity vs priority: how support should use both

Use this when

• Agents and engineers argue about whether something is "P1" or "sev 1"
• Your tracker has one field doing the job of two
• Triage keeps stalling on what a word means
• You are designing an incident taxonomy from scratch

Not for

• Writing your SLA policy (that comes after the taxonomy)
• Deciding on-call rotations
• Root cause analysis of a specific incident
• Customer-facing status page wording

Steps

1. Define severity by damage only, S1 to S4

Severity answers "how broken is it" with no regard for who is affected. S1: core function down for everyone. S2: core function degraded or down for a segment. S3: workaround exists, minor function broken. S4: cosmetic or single-user edge. No business judgment allowed in this field.

Expected output: a four-line severity scale pinned in your runbook.

2. Define priority by business order, P1 to P4

Priority answers "what do we work on first." It can consider revenue, a launch tomorrow, a key account, or contractual penalties. Two S3s can have different priorities, and that is fine.

Expected output: a four-line priority scale that references business factors explicitly.

3. Assign them with different owners

The agent or on-call who sees the damage sets severity. The incident commander or support lead sets priority. One person setting both is how "my ticket is more important" arguments start.

Expected output: your triage doc names who sets each field.

4. Use the matrix, not vibes

High severity with low priority happens: a complete outage in a deprecated product during a migration. Low severity with high priority happens too: a typo on the checkout page during a launch. Plot both, then act on priority order.

Expected output: triage decisions reference both fields in the ticket.

5. Revisit priority on a schedule, severity on facts

Priority decays and shifts as launches pass and workarounds land; review it daily on open incidents. Severity changes only when the damage changes, like a workaround failing or scope expanding.

Expected output: open incidents get a priority review note; severity changes carry a reason.

The two-axis matrix

              P1 (now)      P2 (today)     P3 (this week)   P4 (backlog)
S1 (all down)  all hands     urgent          planned          (rare: note why)
S2 (degraded)  urgent        planned         scheduled        backlog
S3 (workaround exists)  planned  scheduled   backlog          backlog
S4 (cosmetic)  scheduled     backlog         backlog          wontfix candidate

Rule of thumb: an S1 is never P4 without a written reason.
A P1 that is S4 is usually a launch or a key account. Say so in the ticket.

Variant phrasings

difference between severity and priority

Severity is the damage. Priority is the order. One describes the incident, the other describes your response.

should severity and priority be the same thing

No. Collapsing them forces one number to carry two arguments, and every triage becomes a fight about which argument counts.

priority vs severity in incident management

Most incident frameworks (including the common S1-S4 plus P1-P4 pairing) keep both fields for exactly this reason.

Why it happens

Teams merge the fields because it feels simpler: one number, one sort order. But severity is a technical fact and priority is a business decision, and they move on different clocks. A single number either hides real damage (the S1 nobody prioritized) or manufactures urgency (the P1 with a cosmetic bug). Two fields let the facts and the decisions disagree honestly.

Edge cases

• Customer-reported severity: customers always say S1. Let them pick from a customer-facing scale (e.g. "blocking my work"), then map it to your internal severity yourself.
• Priority inflation: if everything is P1, nothing is. Cap the number of concurrent P1/P2 items and force a demotion conversation when the cap breaks.
• Severity changes mid-incident: log it with a timestamp and reason. Severity history is what postmortems audit.
• Contractual SLAs: when an SLA pins response times to severity, say so in the scale definition so agents know the field has legal weight.
• Deprecated products: an S1 in a product you are sunsetting can legitimately be P4. Write the reason down so nobody re-litigates it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1ucGgVQ2WptWv24nlPoBCA

Resolved from the public thread: https://vectle.com/posts/pst_1ucGgVQ2WptWv24nlPoBCA

Thread query: severity vs priority: how support should use both

TL;DR: Severity measures how bad the damage is. Priority measures how fast the business wants it fixed. They are two different axes, and merging them into one number is where triage arguments start. Keep both, let different people set each one, and use the matrix below to decide what happens first.