Incident Severity Levels: P1-P4 Classification Guide

Without incident severity classification, all problems seem equally critical. Server down for 30 seconds? P1. CSS not loading? P1. Both require immediate response—and your team burns out in a month. Proper P1-P4 classification lets you allocate resources smartly: respond fast to real crises and handle routine issues efficiently.

This guide defines clear boundaries between levels, shows how to decide in gray areas, and explains the relationship between severity and response time. Goal: your team spends hours on what truly matters, not fighting false alarms.

Why Classification Matters

Imagine your company has no classification, only alerts. Something unusual happens—everyone gets an SMS. Then you figure out what happened, and soon:

• On-call engineer can't sleep at night (even minor issues wake them)
• Team stops trusting alerts (alert fatigue)
• Real critical incident at 3 AM goes unnoticed because calls are lost in the noise
• Burnout and staff turnover

Classification creates a contract: "P1 is when you call, P2 is when you message, P3 is check tomorrow". Clear rules reduce stress and increase effectiveness.

P1: Critical

P1 Examples

• Complete outage: all three regions down simultaneously
• Data loss: database corrupted, transactions lost
• Security breach: vulnerability discovered, attacker has access
• Payment processing down: payments not going through, revenue lost
• Authentication broken: no one can log in, app is useless

Actions for P1

• Call on-call engineer by phone (not Slack)
• Summon incident commander and start video call
• Start communication channel (update status every 15 minutes)
• All leaders on Zoom observing and helping with decisions
• Meanwhile: root cause analysis (RCA) can wait, stabilization is priority

P2: Major

P2 Examples

• One region down: EU users can use US, but with latency
• Degradation: API works but responds in 5+ seconds instead of 200ms
• Partial feature down: data export broken, but rest works
• Database connection pool exhausted: new requests hang, old ones work
• Memory leak in worker: processes crash each hour, but auto-restart

Actions for P2

• Message on-call engineer (SMS included)
• Create incident in Slack and invite team
• No need to call CEO, but team lead must know
• Update status page (if public) every 30 minutes
• Simultaneously collect information for RCA

P3: Minor

P3 Examples

• CSS broken on settings page: buttons invisible, but function works via API
• Email notifications delayed: arrive an hour late, but they arrive
• One user cannot log in: specific to one person (might be browser)
• Timezone conversion bug: users from one country get wrong timezone
• Documentation page 404: docs unavailable, but function works

Actions for P3

• Create issue in issue tracker
• Post to Slack (text, no @here)
• On-call engineer will check during day in bug fix time block
• No emergency response needed
• Can be resolved next sprint

P4: Low

P4 Examples

• Typo in docs: "montioring" instead of "monitoring"
• Button color slightly off: gray shade instead of dark gray
• Exception message unclear: shows "Internal Error 500" instead of reason
• Performance could be better: API responds in 100ms, ideally 50ms
• Feature request: users want Excel export (CSV already exists)

Actions for P4

• Create issue in backlog
• Post in general channel (no urgency)
• Engineer will check when they have free time
• This doesn't block anyone

Response Time Table

Gray Areas: How to Decide

Not all issues fit cleanly in one category. Here's how to think about edge cases.

Case: One API endpoint is slow

Questions: Which endpoint? How many users affected? Is there a workaround?

• If it's checkout API affecting 10% of payments → P1 (revenue loss)
• If it's analytics API affecting 50% of data → P2 (works slowly)
• If it's notifications API delayed 2 hours → P3 (arrives later)

Case: Error spike in logs

Questions: Is this a real feature failure? Do users see it?

• If it's payment processing exception → P1 (payments fail)
• If it's cache update warning → P3 (self-healing)
• If it's debug log accidentally on ERROR level → P4 (false alarm)

Rule of Thumb

Severity vs Priority: Key Difference

Severity = how bad the situation (losses). Priority = how fast to respond (urgency).

Key takeaway: prioritize severity and priority independently, then combine. P4 can be urgent, P2 can be deferred.

Escalation Rules

Common Mistakes

Mistake 1: Severity Inflation (Everything P1)

Team classifies routine issues as P1 to fix faster. Result: on-call engineer sleeps poorly, alert fatigue, real P1s missed. Solution: audit classifications. Monthly review: "Was this really P1?" Train team if not.

Mistake 2: No Clear Definitions

Each engineer interprets P2 vs P3 differently. One thinks "API slow" is P2, another says P3. Result: chaos. Solution: document clear criteria, show examples, update with experience. Make it part of on-call playbook.

Mistake 3: Severity Doesn't Change

Classified as P1, later found it's P3, but no downgrade. Team wastes hours. Solution: re-evaluate as info arrives. Tell stakeholders: "We believe this is P3, not P1, because..."

Mistake 4: Severity == Priority

Think high severity means high priority. But P4 bug for CEO may be more critical than P2 for one user. Solution: separate severity and priority. Classify both.

Severity and Monitoring: Practical Application

Proper classification in monitoring directly connects to severity levels. AtomPing lets you configure alert policies so different incidents trigger different channels.

Target: API Server (eu-fra1, us-east-1, ap-sin1)

Rule 1 - P1 (Critical):
  Trigger: 3+ regions DOWN in same cycle
  Channels: PagerDuty + SMS + call
  
Rule 2 - P2 (Major):
  Trigger: 1 region DOWN or DEGRADED for 2+ cycles
  Channels: Slack #incidents + email
  
Rule 3 - P3 (Minor):
  Trigger: 1 region slow (TTFB >2s) for 3+ cycles
  Channels: Email only

Using this configuration, you ensure P1 gets immediate attention, P2 is handled properly, and P3 doesn't spam channels.

Checklist: Is Your Team Ready?

Summary

Severity classification P1-P4 isn't bureaucracy, it's a tool for sane incident response. Clear definitions reduce stress, prevent burnout, and ensure critical incidents get proper attention.

Remember: your team is overloaded because everything is urgent. Proper severity classification frees capacity for what truly matters.

Related Resources

• → Incident Management Guide — complete incident management from alert to RCA
• → On-Call Rotation Best Practices — how to organize on-call rotation to prevent burnout
• → Incident Communication Templates — ready-to-use message templates for each severity level
• → Post-Incident Review Guide — how to conduct blameless RCA and prevent recurrence