SEVERITY

Incident Priority (SEV Levels)

A classification system (P0-P4 or SEV1-SEV5) that determines the urgency and response time required for an incident.

Priority

A classification system (P0-P4 or SEV1-SEV5) that determines the urgency and response time required for an incident.

P0-P4 Priority Levels

P0 (Critical): The house is on fire. All hands on deck. Revenue stopped or data loss at risk. Examples: Site down, payment processing failed, security breach, data corruption.

P1 (High): Major functionality degraded. Core user journey affected but partial workaround exists. Examples: Checkout fails for some users, search is down, login requires password instead of SSO.

P2 (Medium): Non-critical features broken. Fix during business hours. No immediate revenue impact. Examples: Reporting dashboard down, user profile edits broken, export functionality fails.

P3 (Low): Minor issues with no user impact. Fix when convenient. Examples: Button slightly misaligned, minor formatting issue, non-critical UI inconsistency.

P4 (Trivial): Cosmetic only. Fix whenever. Examples: Typo in footer, extra space in header, formatting issue on documentation page.

Priority vs Severity

Priority determines fix order and can change based on business context. Severity measures technical impact and stays fixed. They usually correlate (P0 ≈ SEV0, P1 ≈ SEV1), but business context can create divergence: a broken internal dashboard might be SEV0 for the CEO but remain P2 if customers aren't affected.

SEV Level Mapping

Priority | Severity Equivalent | Response Expectation
Priority Severity Equivalent Response Expectation
P0 SEV0 Immediate: Ack within 5 min, update every 15 min
P1 SEV1 Urgent: Ack within 15 min, update within 30 min
P2 SEV2 Standard: Ack within 30 min, update within 1 hour
P3 SEV3 Normal: Ack within 4 hours, fix within 1 business day
P4 SEV4 Backlog: Fix when bandwidth allows

Classification Rules

  1. Any revenue impact or data loss → P0
  2. Customer-facing core functionality broken → P0 or P1
  3. Non-critical customer features broken → P2
  4. Internal tools broken → P2 or P3
  5. Cosmetic issues only → P4
  6. When unsure, default to lower priority to prevent alert fatigue

ExFinTech Platform Priority Classification

Payment processing fails at 2 AM on a Saturday. P0 because revenue stops immediately. Automated paging to VP Engineering and 5 senior engineers based on "revenue-stopping" rule.

Impact
Payment processing restored in 18 minutes, $900K in transactions protected
Resolution
Built automatic failover to backup payment provider

Why Priority Matters

Sets expectations for response time (SLAs).

Prevents burnout by ensuring you only wake people up for real emergencies.

Common Pitfalls

Classifying everything as P0 "just in case"
P0 should be rare (<5% of incidents). Over-classification causes alert fatigue and leads to ignored pages.
No clear criteria for priority levels
Create a severity matrix with specific examples. Train all team members on classification criteria.

Related Terms

Generate Your Severity Matrix

Benchmark against industry standards and identify improvement opportunities.

Launch Tool

Frequently Asked Questions

Put this into practice.