Your team must decide how to label incidents and which ones page someone at night. There is no single standard for these labels. This post gives a four-level example, the difference between priority and severity, a priority matrix and how levels connect to escalation.
What are P1, P2, P3 and P4 incidents?
P1, P2, P3 and P4 are incident priority levels, with P1 as the most urgent and P4 as the least. These labels tell your team how quickly to respond and who needs to act.
| Level | Also called | What it means | Example | Typical response |
|---|---|---|---|---|
| P1 / SEV1 | Critical | The service is down or a core function is broken for most users, or data is at risk | Checkout fails for every customer | Page the on-call person now, at any hour; escalate fast |
| P2 / SEV2 | High | A major function is degraded or broken for a subset of users; a workaround may exist | Payments slow for one region | Page now during the rotation; escalate if not acknowledged |
| P3 / SEV3 | Moderate | A minor function is broken or degraded; limited user impact | A report export fails | Notify; handle during working hours |
| P4 / SEV4 | Low | Cosmetic issue or no current user impact | A dashboard label is wrong | Ticket; next planned work |
This table is an example, not a standard. Numbering varies across companies. Write your own definition and example for each level and publish it.
Priority vs severity: what is the difference?
Severity describes impact. It measures how badly the service and its users are affected. Priority describes urgency and order. It determines how fast the team must respond and which work goes first.
Many teams use one scale for both concepts. ITIL-style teams derive priority from impact and urgency. See the matrix section for that logic.
In both schemes, the lower the number, the more severe the incident. A P1 is more severe than a P2.
Incident severity levels: SEV1 to SEV4
SEV1: critical
SEV1 means the service is down or a core function is broken for most users, or data is at risk, such as when the checkout fails for every customer. The typical response is to page the on-call person now, at any hour, and escalate fast.
SEV2: high
SEV2 means a major function is degraded or broken for a subset of users, such as when payments are slow for one region, and a workaround may exist. The typical response is to page now during the rotation and escalate if the incident is not acknowledged.
SEV3: moderate
SEV3 means a minor function is broken or degraded with limited user impact, such as when a report export fails. The typical response is to notify the team and handle the issue during working hours.
SEV4: low
SEV4 means the issue is cosmetic or has no current user impact, such as when a dashboard label is wrong. The typical response is to create a ticket and address it during the next planned work cycle.
What is a P0 or SEV0 incident?
Some companies add a level above P1 for the worst case, such as a full outage or security breach, often involving executives. Numbering varies: some start at 0, others at 1. Whatever you choose, define it.
Incident priority matrix: impact and urgency
Use an impact-urgency matrix to derive priority. This ITIL-style example shows how the two factors combine.
| Impact / Urgency | High urgency | Medium urgency | Low urgency |
|---|---|---|---|
| High impact | P1 | P2 | P3 |
| Medium impact | P2 | P3 | P4 |
| Low impact | P3 | P4 | P4 |
Assess impact by counting affected users and measuring service degradation. Assess urgency by estimating how quickly the situation worsens without intervention. Read the priority level where your impact and urgency ratings intersect.
Who gets notified at each level
The level decides who is notified, how fast escalation moves and whether it happens out of hours.
P1 and P2 incidents page the on-call person immediately. If nobody acknowledges the page, the escalation chain moves to the next level. P3 incidents notify the team but are handled during working hours. P4 incidents become tickets for the next planned work cycle.
Low levels should not page anyone at night. Waking someone for a cosmetic issue or a minor bug creates fatigue and reduces attention for real emergencies.
Write these rules into the escalation policy, not people's memory. A policy enforces the same response for every incident.
Response time targets by priority
Teams often set a target time to acknowledge (MTTA, mean time to acknowledge) and a target time to resolve for each level. Set each target from your own incident history rather than an outside benchmark. Review targets after incidents.
How to set incident priority levels for your team
Start with 3 or 4 levels, then work through these steps.
Define each level by user impact. Use a real example from your systems. Do not use abstract descriptions. "Checkout fails for every customer" is clear. "Service degradation" is not.
Decide the response for each level. Specify who gets notified. Set how fast they must respond. State whether the alert pages someone out of hours. Low levels should not wake anyone at night.
Let the on-call person set or change the level. They see the impact first. They know if a workaround exists. Allow them to downgrade a P1 to a P2 if the issue is contained.
Review levels after incidents. Did the team respond correctly? Was the notification appropriate? Adjust definitions if the current ones do not match reality.
Publish the levels where the whole team can find them.
Incident priority in OnCallAlerting
Incidents carry a priority from P1 to P5, which the people handling the incident can set and change. Escalation policies decide who is notified, with a wait of 1-1440 minutes per level. In follow-the-sun rosters, critical alerts can skip the wait.
OnCallAlerting does not route alerts by priority automatically. Each alert source feeds an escalation policy, and the policy decides who is notified; the priority tells responders how urgent the incident is.
See the incident actions docs for setting priority. Read the escalation policies docs for notification rules. Start a 30-day trial to test your setup.