What are standard incident severity levels?

Most teams use a SEV1 to SEV5 scale. SEV1 (Critical) means total outage requiring immediate all-hands response. SEV2 (High) is major functionality broken responding within 15-30m. SEV3 (Medium) is minor issues handled during business hours. SEV4/5 are cosmetic or very low impact logs.

What is the difference between Priority and Severity?

Severity measures the impact of an incident (e.g., 'System is down'). Priority measures the urgency of the response (e.g., 'Fix this immediately'). Often they correlate (High Severity = High Priority), but not always.

Tools/Incident Severity Matrix

SRE TOOLS

Incident Severity
Matrix.

Define clear 5-level severity definitions (SEV0–SEV4 or SEV1–SEV5) to align your team on what's an emergency. Generate, customize, and export to your runbooks.

Load Template:

Level	Description (Impact)	Response Expectation	Examples
SEV0	Catastrophic. Multiple critical services down. Potential data loss.	Immediate war room. Wake everyone. CEO notified.	Database corruption, multi-region outage, security breach with data loss.
SEV1	Critical impact. Core service down for all customers.	Immediate response. Wake up on-call. All hands on deck.	Total outage, payment system down, authentication broken.
SEV2	Major impact. Significant functionality broken or degradation.	Immediate response. Primary on-call handles.	Checkout failing, slow API, core feature broken.
SEV3	Minor impact. Partial failure or non-critical bug.	Fix during business hours. Don't wake up.	Minor feature broken, intermittent errors, reporting delay.
SEV4	Low priority. Cosmetic issues or enhancement requests.	Backlog. Fix when convenient.	Typos, UI polish, nice-to-have features.

Why define severity levels?

Clear severity definitions prevent "everything is a crisis" fatigue. When everyone knows what a SEV0 is versus a SEV3, on-call engineers can prioritize effectively and avoid burnout.

Why You Need a Severity Matrix

Without clear severity definitions, every alert feels like a fire drill. This leads toalert fatigue, where on-call engineers stop taking alerts seriously because "everything is urgent."

A good severity matrix answers two questions instantly:

How bad is this? (Impact)
How fast do I need to fix it? (Response SLA)

Best Practices

✓
Keep it simple: Don't overcomplicate definitions. "Is money being lost?" is a good binary check.
✓
Print it out: Have this pinned in your Slack incident channel topic.
✓
Automate it: Use tools like Runframe to automatically set severity based on alert tags.

Standard Severity Levels

A common 5-level framework used by many high-performing teams (often SEV0–SEV4).

SEV0

Catastrophic

Impact: Multiple critical services down. Potential data loss. Company-wide impact.

Response: Immediate war room. Wake everyone. CEO notified.

SEV1

Critical Emergency

Impact: Core service down for all users. Revenue stopping.

Response: Immediate (Wake up). All hands on deck.

SEV2

Major Incident

Impact: Significant feature broken or major degradation.

Response: Immediate (Wake up). Primary on-call handles.

SEV3

Minor Incident

Impact: Partial failure, slow performance, or non-critical bug.

Response: Next business day (Don't wake up).

SEV4

Low Priority

Impact: Cosmetic issues, minor bugs, or enhancement requests.

Response: Backlog. Fix when convenient.

Note: Some teams use SEV1-5 instead of SEV0-4. Both systems have 5 levels—the difference is just numbering. SEV0 emphasizes that "zero" means everything is on fire 🔥

Incident Severity Matrix.