severity definitions for support escalations

TL;DR

Severity measures technical impact: how broken, how widespread, how much workaround exists. S1 is the product is down or data is at risk; S4 is a cosmetic annoyance with a workaround. The most important rule: severity is never set by how loud the customer is. Write the definitions with examples so nobody has to interpret them under pressure.

The query

severity definitions for support escalations

Use this when

• Agents and engineers argue about severity
• Escalations arrive with inflated severities
• You are writing the escalation policy
• Severity inflation is drowning real S1s

Not for

• P1 vs P2 vs P3 priority ranking (priority is business ordering, severity is technical impact)
• SLA response-time design
• Customer-facing status page language
• Engineering sprint prioritization

Steps

1. Define S1: critical, act now

Core functionality down for many users, data loss or corruption in progress, or a security incident. No workaround. Page someone immediately. Example: all logins failing, or exports silently dropping customer data.

Expected output: everyone agrees what a drop-everything event looks like.

2. Define S2: major, same-day

A key feature broken for a meaningful segment, or degraded performance with no workaround. Needs engineering today but not a page at 3am. Example: the reporting dashboard wont load for Pro accounts.

Expected output: a clear line between "now" and "today."

3. Define S3: moderate, this week

A feature broken with a viable workaround, or a minor feature broken outright. Frustrating but not blocking. Example: CSV export works but date formats are wrong and the customer can fix them in a spreadsheet.

Expected output: the workaround question becomes the S2/S3 dividing line.

4. Define S4: minor, backlog

Cosmetic issues, typos, small UX papercuts. Annoying, never blocking. Example: a misaligned button on the settings page.

Expected output: S4s stop consuming urgent attention.

5. Write the anti-inflation rules

Severity follows impact, not volume, not tone, not account size alone. One angry enterprise customer with a workaround is still S3. Put this in writing or every escalation becomes S1.

Expected output: a severity guide that resists pressure.

Ready-to-use definitions

S1 CRITICAL: core function down for many, or data/security at risk.
    No workaround. Page immediately.
S2 MAJOR: key feature broken for a segment, no workaround.
    Engineering today.
S3 MODERATE: broken with a workaround, or minor feature broken.
    Fix this week.
S4 MINOR: cosmetic or trivial. Backlog.

Severity = technical impact. Never set by customer tone or volume.

Variant phrasings

support escalation severity levels explained

Steps 1 through 4 with the examples. Examples are what make definitions stick.

S1 S2 S3 S4 definitions for support teams

The ready-to-use block. Post it where escalations are filed.

severity vs priority in support escalations

Severity is how broken it is; priority is how soon it gets fixed given everything else. An S3 for your biggest account can be P1. Keep the two axes separate.

Why it happens

Severity inflation happens because severity feels like the only lever support has to get attention. When every escalation is S1, the real S1s drown, and engineering stops trusting the labels entirely. Precise definitions protect the signal by making inflation visible.

Edge cases

• A single huge account down: severity is still about technical scope, but note the account impact separately. Dont bend the definition; add context.
• Security issues: default to S1 until security says otherwise. Over-severity here is the one safe direction.
• Degradation vs outage: partial degradation with a workaround is S2, not S1. "Slow" is not "down."
• Severity changes mid-incident: allow it, but log who changed it and why. Severity that drifts silently corrupts the data.
• Customers demanding S1: acknowledge, assess honestly, and explain the call. Never upgrade severity to end a conversation.

Provenance

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

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

Thread query: severity definitions for support escalations

TL;DR: Severity measures technical impact: how broken, how widespread, how much workaround exists. S1 is the product is down or data is at risk; S4 is a cosmetic annoyance with a workaround. The most important rule: severity is never set by how loud the customer is. Write the definitions with examples so nobody has to interpret them under pressure.