Incident severity levels and priority are not the same thing
Many teams use the two words interchangeably, and it causes confusion when a ticket says SEV3 and P1 at the same time. A useful split is this:
- Severity describes impact: how badly the service is affected and for how many people. It is a statement of fact about the incident.
- Priority describes the order and speed of response: how urgently the team acts relative to everything else. It is a decision.
Most of the time they line up, and many engineering teams use one scale for both. They diverge in cases like a minor defect in a payment flow on the last day of the quarter (low severity, high priority) or a full outage of an internal tool at 2 a.m. on a Sunday (high severity for a small group, lower priority until morning). If your team uses SEV levels for incidents, read our companion guide on incident severity levels and use priority for the order of work.
The incident priority matrix of impact times urgency
The IT service management approach popularised by ITIL derives priority from two inputs instead of one gut feeling. Impact is how much of the business is affected. Urgency is how quickly the impact grows or becomes costly if nothing is done.
| Impact / Urgency | High urgency | Medium urgency | Low urgency |
|---|---|---|---|
| High impact | P1 | P2 | P3 |
| Medium impact | P2 | P3 | P3 |
| Low impact | P3 | P4 | P4 |
Define impact in terms your team can check in a minute, not in adjectives:
- High impact: a core user journey fails (sign in, checkout, API writes), data is at risk, or a large share of customers is affected.
- Medium impact: a feature is degraded or slow, a workaround exists, or a limited group of customers is affected.
- Low impact: cosmetic issues, internal-only tooling, a single customer with a workaround.
Define urgency by what happens with time:
- High urgency: damage grows by the minute, such as lost orders, a security exposure or a breached contractual commitment.
- Medium urgency: damage grows over hours.
- Low urgency: the situation is stable and can wait for normal working hours.
P1 to P4 definitions and response targets
The targets below are a reasonable starting point for a software team. Adjust them to your contracts and service level objectives, then publish them where every responder can see them.
| Priority | Typical example | Who is engaged | Acknowledge within | Updates |
|---|---|---|---|---|
| P1 | Checkout fails for all users, data loss risk | Primary on-call paged immediately, incident commander, comms lead | 5 minutes, day or night | Status page and stakeholders every 30 minutes |
| P2 | Checkout slow or failing for one region | Primary on-call paged, escalation if not acknowledged | 15 minutes, day or night | Status page if customers notice, internal updates hourly |
| P3 | Export feature broken, workaround exists | Owning team during business hours | Next business hour | Ticket updates |
| P4 | Minor UI defect, one customer affected | Owning team backlog | Next business day | Ticket only |
Two rules make the table work in practice. First, only P1 and P2 page anyone outside working hours. If a P3 wakes someone up, either it is really a P2 or the alert is misconfigured. Second, the acknowledgement target is enforced by the escalation policy, not by good intentions: if the primary does not acknowledge a P1 in five minutes, the page goes to the secondary automatically.
How to assign priority during an incident
- Assign early, revise freely. The first responder sets an initial priority within minutes. Upgrading or downgrading later is normal and should be recorded on the timeline, not treated as a mistake.
- When in doubt, go higher. Downgrading a P1 costs a few minutes of attention. Treating a real P1 as a P3 costs hours of customer impact.
- Let anyone raise it. Support, sales or an engineer from another team should be able to escalate priority when they see impact the on-call does not.
- Tie priority to actions. Each level should trigger something concrete: who is paged, whether a status page update is required, whether a postmortem is required.
Edge cases worth deciding in advance
- Security incidents: many teams treat any confirmed security incident as P1 regardless of visible impact, and route it to a separate security on-call.
- Single large customer: decide whether a contractual customer counts as high impact on its own. Writing it down avoids an argument at 3 a.m.
- Internal tools: an outage of CI or the deploy pipeline blocks every fix, so it can deserve P2 even though no customer sees it.
- Third-party outages: priority follows your customers' impact, even when the fix is out of your hands. Your work is communication and mitigation.
Why priority schemes fail
- Too many levels. Five or six levels invite debate about the difference between P3 and P4. Four is enough for most teams.
- Priority by who complained loudest. Without written criteria, priority follows seniority instead of impact.
- Everything is P1. If most incidents are P1, the level stops meaning anything and responders stop reacting to it. Review the distribution each quarter.
- No link to paging. A priority that does not change who gets paged, or how, is only a label.
Make priority drive paging, roles and updates
In IncidentBot, severity levels and custom fields are set when the incident opens in Slack, and they drive the rest of the response: which escalation policy pages whom, which roles are assigned, and whether a status page update is drafted. See how the pieces connect on the incident response tools page, build the paging side with on-call scheduling, and check which plan includes custom fields on the pricing page. You can also watch a SEV level change the paging path in the incident simulator.