Before you can manage an incident, everyone involved must agree on how bad it is. Without a shared definition, one engineer's "SEV1 emergency" is another's "fix it tomorrow." Severity Levels (commonly called SEV levels) categorize incidents based on their actual impact on customers and the business. The severity level determines urgency, who gets notified, and what response process kicks in.
While exact definitions vary by company, the following model is widely used across the industry. What matters most is that your organization defines these levels explicitly and trains everyone on them before an incident happens — not during one.
SEV1: Critical / Catastrophic
- Impact: The entire service is down or completely unusable. No customers can complete core workflows. Significant revenue loss or reputational damage is occurring in real time.
- Response: All hands on deck. On-call engineers are paged immediately. An Incident Commander (IC) is assigned to run a live "war room" bridge call. Executive stakeholders are notified. All other work stops.
- Example: The main e-commerce website returns 503 errors to all users on Black Friday. Every minute of downtime costs tens of thousands of dollars.
SEV2: Major
- Impact: Major functionality is broken or severely degraded. The service is partially usable, but a critical workflow — like checkout, login, or payment processing — is failing for a significant percentage of users.
- Response: Urgent. On-call engineers are paged. The issue is addressed immediately, but may not require a full all-hands bridge call if a single team can own the fix.
- Example: Users in Europe cannot process credit card payments, but PayPal and bank transfers still work.
SEV3: Minor / Moderate
- Impact: Partial, non-critical loss of functionality. A small subset of users is affected, or a non-essential feature is broken. A workaround exists.
- Response: Addressed during business hours, or deprioritized behind active SEV1/2 incidents if the on-call engineer is already engaged.
- Example: The "export to PDF" button on a reporting dashboard is broken. Users can export to CSV instead.
SEV4 / SEV5: Trivial / Cosmetic
- Impact: Minor bugs, UI glitches, or typos that don't affect core functionality or user workflows.
- Response: File a ticket in the normal development backlog and fix it in the next sprint.
- Example: A button label says "Submitt" instead of "Submit."
Why Severity Definitions Matter
The real value of severity levels is not the label — it's the automatic response protocol attached to each level. When a SEV1 fires, nobody should be asking "should we page the on-call?" That decision was made in advance. Ambiguity during an incident costs time, and time costs customers.
Interviewers often ask: "How do you decide what severity to assign an incident?" The trap is giving a vague answer like "it depends on impact." A strong answer names specific criteria: blast radius (how many users affected), revenue impact, whether a workaround exists, and rate of degradation (is it getting worse?). Bonus points for mentioning that severity can be upgraded mid-incident as more information surfaces — a SEV3 that turns out to affect all enterprise customers should immediately be re-classified as SEV2 or SEV1.