How to Draft an Incident Severity Classification in English
Learn the English vocabulary for classifying and communicating incident severity levels (SEV1 through SEV4), including how to justify and change a severity rating clearly.
Assigning and communicating a severity level during an incident needs to happen quickly and be understood instantly by everyone reading it, from engineers to executives. The English used here is deliberately compact and standardized — vague severity descriptions slow down response and create confusion about who needs to be paged. This guide covers the vocabulary for classifying and clearly communicating incident severity.
Key Vocabulary
Severity level — a standardized classification (commonly SEV1 through SEV4, or P1 through P4) indicating how serious an incident is, used to determine response urgency and who gets involved. “We’re classifying this as a SEV2 — significant customer impact, but not a full outage.”
Customer impact — a description of how an incident affects end users, expressed as specifically as possible (which users, what functionality, roughly what proportion), rather than a vague “some users are affected.” “Customer impact: approximately 15% of checkout attempts are failing; browsing and account functions are unaffected.”
Blast radius — the scope of systems, services, or users affected by an incident, used to help responders and stakeholders quickly understand how contained or widespread the problem is. “The blast radius is limited to the EU region — US and APAC traffic is unaffected.”
Escalation criteria — the specific conditions under which an incident’s severity should be raised or lowered, defined ahead of time so severity decisions aren’t made ad hoc during a stressful incident. “Per our escalation criteria, any incident affecting payment processing automatically starts at SEV2, regardless of how many users are currently affected.”
Re-classify — to formally change an incident’s severity level as new information becomes available, which should always be stated explicitly and explained, not silently changed. “We’re re-classifying this from SEV3 to SEV2 — the initial reports understated the customer impact.”
Common Phrases
- “We’re classifying this as a [SEV level] based on [customer impact / blast radius].”
- “Customer impact is currently [specific description], and we expect [update on scope].”
- “Per our escalation criteria, this automatically qualifies as a [severity], regardless of current scope.”
- “We’re re-classifying this to [level] because [new information].”
- “This does not meet the threshold for [higher severity] — here’s why.”
Example Sentences
Declaring an incident’s initial severity: “We’re classifying this as a SEV1: the primary authentication service is fully down, meaning no users can log in. Blast radius is global — this affects all regions and all product surfaces that require authentication.”
Explaining a re-classification: “We’re re-classifying this incident from SEV2 to SEV3. The initial alert suggested broad impact, but investigation shows it’s affecting a single internal admin tool, not customer-facing traffic. Customer impact is effectively zero.”
Justifying a severity decision to a stakeholder questioning it: “I understand this feels urgent from your side, but per our escalation criteria, a SEV1 requires either a full outage or a security incident, and this is neither — it’s a degraded experience for a small subset of users. We’ve classified it SEV3 and are treating it accordingly, but I’m happy to revisit if the scope changes.”
Professional Tips
- Always pair a severity level with a concrete description of customer impact and blast radius — the level alone (“this is a SEV2”) tells a reader little without that context.
- Reference escalation criteria explicitly when justifying a severity decision, especially if someone is pushing for a different classification — it grounds the decision in a predefined standard rather than personal judgment in the moment.
- State re-classifications explicitly and explain what new information drove the change — silently changing a severity level without explanation erodes trust in the process.
- Use precise numbers or percentages for customer impact wherever available (“15% of checkout attempts”) rather than vague terms like “some” or “a lot,” which different readers will interpret very differently.
Practice Exercise
- Write a one-sentence severity declaration for a hypothetical incident, including customer impact and blast radius.
- Draft a two-sentence explanation for re-classifying an incident from SEV3 to SEV1.
- Explain, in one sentence, why escalation criteria should be defined before an incident happens rather than during one.