Severity Is Assigned Before Anyone Knows the Impact: A Decision Procedure for Declaring Under Uncertainty

TL;DR Incident severity levels measure the business impact of a software failure, but they are almost always declared at the two-minute mark before the full blast radius is known. To avoid SEV1 inflation or delayed responses, teams must use a decision procedure based on observable technical evidence—like symptom shape and change proximity—rather than guessing user counts.

The two-minute problem

It is 21:05. Your checkout error rate spikes from 0.2% to 4%. You have one region reporting failures, and there have been no recorded deploys in the last hour. As the first responder, you are expected to pick one of several incident severity levels right now.

The problem is that every published severity table asks a question you cannot possibly answer yet: How many customers are affected? According to [Atlassian], severity is a measurement of impact, but in the first moments of a software incident, impact is a mystery. You are forced to choose between over-declaring (burning your escalation path) or under-declaring (violating SLAs). We must accept that severity is declared from evidence, not from impact, because impact is not knowable at the moment of declaration.

What the standard tables actually say, and what they assume

Most organizations rely on a standard incident severity matrix to guide their response. These frameworks are useful for retrospective categorization, but they struggle in the "fog of war."

• Atlassian: Defines SEV1-3 based on whether a service is "down for all" or "partially degraded." Their examples are largely retrospective.
• InvGate: Uses an ITIL-based impact-times-urgency matrix. This assumes you have two known inputs, which is rarely the case at minute two of a production outage.
• FireHydrant: Connects severity to SLA-proximity, focusing on how quickly a breach will occur. This is highly actionable but assumes you know the clock speed of the failure.
• incident.io: Candidly admits that severities are subjective. Their advice is often to "pick the higher level" when in doubt to ensure resources are mobilized.

The common thread is that every table is a function of impact, and every worked example is written in the past tense. They tell you how to label the fire once it's out, not how to judge the smoke while you're holding the extinguisher.

Incident severity vs priority

Before refining the procedure, we must distinguish between incident severity vs priority.

• Severity is the technical measurement of the damage (e.g., the database is corrupted).
• Priority is the order in which you should fix things (e.g., the homepage typo needs to be fixed immediately because it’s a PR disaster, even if the "severity" is low).

A high-severity item usually demands high priority, but the two can diverge. A broken internal admin tool for a team on vacation is high severity (total loss of function) but low priority.

Declaring from evidence: The five signals you have at minute two

To determine how to determine incident severity without knowing the user count, look at the technical evidence across your stack:

1. Symptom Shape: Is it a step change or a creep? A step change (0 to 100) implies a hard failure or a configuration flip. Latency creep implies resource exhaustion (memory leaks, queue backing up).
2. Blast Surface: You can't count users, but you can count entry points. Is it one endpoint, one region, one tenant, or one background worker? Bound the surface to bound the risk.
3. Change Proximity: Did a deploy, feature flag flip, or infra migration happen in the last 10 minutes? According to [FireHydrant], change is the leading cause of incidents. Knowing a change is "in the window" is the highest-information fact you have.
4. Reversibility: Is the failure on the read-path or write-path? A read-path failure (can't see dashboard) stops when the bug is fixed. A write-path failure (corrupted orders) creates a "data debt" that must be reconciled later. Write-path failures should almost always be graded one level higher.
5. Ceiling Detectability: Do you have a metric that shows you the worst-case scenario? If you are "blind" to the depth of a queue or the state of a secondary region, you must assume the worst.

The declaration rule

When determining how response teams determine the severity of an incident, follow this decision procedure:

1. Identify the highest plausible outcome consistent with the current evidence.
2. If the failure is on a write-path, escalate by one level.
3. In the first status update, state: "Impact not yet determined, grading based on [Signal X]." Never state "no impact" unless you have evidence of a null set.

Key Takeaway: Severity is an evidence problem, not a taxonomy problem; grade based on the highest plausible risk indicated by your current technical signals.

Re-grading is the practice, not the exception

If you declare severity based on partial evidence, your incident severity rating should change as more data arrives. A severity that never changes suggests the team isn't actually investigating the impact.

Establish explicit re-grade triggers:

• The blast surface expands (e.g., a second region starts failing).
• A change is confirmed as the root cause.
• A fixed timebox expires (e.g., reassess every 15 minutes).

Keeping both the original and the revised level is vital. The delta between the "Declared Severity" and "Final Severity" is the only way to measure how well your team reads early-stage evidence.

Auditing severity after the fact

To improve your severity level classification, track these three metrics:

1. Under-declaration Rate: How often was the final severity higher than the initial? This costs money and indicates a culture of "wait and see" that delays response.
2. Median Time to First Re-grade: How quickly do you move from "guessing" to "knowing"?
3. The Over-declaration Ratio: If 90% of your SEV1s are downgraded to SEV3s within ten minutes, your escalation paths will eventually be ignored.

Why grading is hard (and how to fix it)

Grading well at minute two is difficult because the evidence is scattered. You have to check CI/CD logs, cloud provider status pages, and distributed traces simultaneously.

This is where Operate changes the workflow. Operate assembles the "change window"—identifying every deploy, migration, and infrastructure shift—and maps it against the affected surface. Instead of a responder guessing the incident severity score, they are presented with a unified view of the evidence. Operate is a self-hosted, read-only platform that helps humans make better decisions without ever touching production or taking autonomous actions.

A worked example: The 21:05 Checkout Spike

• 21:05: Error rate hits 4%. Evidence: Step change, write-path (checkout), no recent deploys. Declared: SEV2 (Plausible major impact).
• 21:15: Logs show errors are isolated to the "Legacy-Pay" provider. Evidence: Surface is bounded. Action: Maintain SEV2.
• 21:25: Operate identifies an uncommunicated API change from the provider. Evidence: External change proximity confirmed.
• 21:30: Impact analysis shows only 1% of total traffic uses Legacy-Pay. Re-grade: SEV3.

FAQ

How do you determine incident severity? Severity is determined by assessing the impact on users and business operations. Use a combination of symptom shape, blast surface, and the reversibility of the data loss.

How is the severity of an incident assessed when impact is unknown? Assess based on technical evidence. Look for change proximity (recent deploys) and the criticality of the affected component (read-path vs. write-path) to estimate the highest plausible risk.

What is the difference between severity and priority? Severity measures the intensity of the failure (e.g., the system is down), while priority measures the urgency of the fix (e.g., how quickly do we need to restore this specific function?).

What are P1, P2, P3, and P4 incidents? These are priority levels often mapped to severity. P1 is a critical business-stopper requiring 24/7 response; P2 is a major issue with high urgency; P3 is a minor issue handled in business hours; P4 is cosmetic or low-impact.

Sources & further reading

• According to [Atlassian], priority is often more actionable than severity for internal task management.
• According to [incident.io], keeping the history of severity changes is essential for long-term learning.
• According to [FireHydrant], the best way to ensure severity is set is to automate the prompt during the incident kickoff.