When something breaks at two in the morning, nobody wants to debate how serious it is. Severity levels settle that debate in advance. They give everyone the same vocabulary, so a small team knows who to wake, how fast to move and what can safely wait until Monday. This guide answers the questions teams ask most when they set up P1 to P4 levels for the first time.
What are incident severity levels?
A severity level is a label that describes how bad an incident is, based on its impact on customers or the business. Each label comes with an agreed reaction: who is alerted, how quickly someone must respond and how often updates go out. “P” stands for priority, and P1 is the most urgent. Some teams write SEV1 to SEV4 instead; the idea is identical.
Why does a small team need them?
With five or ten people, it is tempting to say “we just know when it is serious.” In practice, that means every problem feels urgent to whoever noticed it, the loudest voice sets the priority, and the person on call gets woken for a typo on a settings page. Written levels protect your attention, which is the scarcest resource a small team has.
How many levels should you use?
Four is the sweet spot. Three often forces you to lump serious and moderate problems together, while five or six creates arguments about the line between two neighbouring levels. If people cannot recall the levels without opening a document, you have too many.
How do you decide which level an incident gets?
Ask three questions, in this order:
- How many people are affected? Everyone, a segment, or a single user?
- How badly? Is the service down, partly degraded or merely annoying?
- Is there a workaround? If users can still get their work done another way, the incident is usually one level lower.
Then apply two overrides. Anything involving data loss, a security breach or a legal obligation moves up at least one level. And if you are unsure between two levels, choose the higher one, then lower it once you know more. Downgrading is cheap; a missed emergency is not.
What does a sample P1–P4 scale look like?
Adapt these numbers to your own hours and capacity. They are internal response targets, meaning how quickly your team reacts, which is different from what you promise customers in an agreement.
- P1 – Critical. The service is down or unusable for most users, or data is being lost or exposed. Target: acknowledge within 15 minutes, any hour of the day; an update every 30 minutes; the whole team drops other work.
- P2 – High. A major feature is broken or badly degraded, or an important customer is blocked, with no reasonable workaround. Target: acknowledge within 1 hour during extended hours; an update every 2 hours; fix the same day.
- P3 – Medium. A secondary feature is failing or performance is poor, but a workaround exists. Target: acknowledge within 1 business day; fix within the current week; no out-of-hours alert.
- P4 – Low. A cosmetic issue, a minor bug or a question with no business impact. Target: acknowledge within 3 business days; schedule into the normal backlog.
Who sets the severity, and can it change?
Whoever first handles the incident, usually the person on call, proposes a level using the questions above. The incident lead can change it at any time, and the change should be announced in the same channel so nobody works from stale information. Severity is a living label: a P2 that turns out to affect everyone becomes a P1, and a P1 that is contained with a quick rollback drops to P3 while the root cause is investigated.
What mistakes should you avoid?
- Defining levels by cause. “Database problems are P1” is a trap. Define by impact, not by which system failed.
- Making everything a P1. If every alert is critical, none is. Reserve P1 for real emergencies, or people stop responding.
- Vague wording. “Significant impact” means something different to everyone. Use numbers where you can, such as a percentage of users or a revenue process.
- No update rhythm. Silence during an incident causes more stress than the problem itself. Promise an update interval and keep it, even when the update is “still investigating.”
- Never reviewing the scale. After each P1 or P2, ask whether the level and the response matched reality, and adjust the definitions.
How do you keep the scale working over time?
Put the one-page definition where the team will see it: pinned in your chat channel, linked from your alert tool and printed in the on-call handbook. Log every incident with its level, time to acknowledge and time to resolve, then look at the numbers monthly. If you already manage operations in FulcrumGrid Command Center, you can track incident counts and response times next to your other KPIs, which makes it easy to see whether P2s are creeping up. A spreadsheet works just as well to start with; the habit matters more than the tool.
Start with four levels, write each one in two sentences, attach a response target and test it on your last five real incidents. If the labels feel right in hindsight, you are ready to use them live.
Frequently asked questions
What is the difference between severity and priority?
Severity describes the impact of the incident; priority describes the order in which you work on it. Small teams usually merge the two into one P1 to P4 scale, which is fine as long as the definitions are clear.
Is P1 or P4 the most serious level?
P1 is the most serious and P4 the least. Some tools use SEV1 to SEV4 with the same meaning, but a few reverse the order, so always write down which end of the scale is urgent.
Do we need out-of-hours alerts for every level?
No. Page people outside working hours only for P1, and perhaps P2 if your customers depend on you around the clock. P3 and P4 can wait for the next working day.
How often should we revisit our severity definitions?
Review them after any P1 or P2 incident and do a full check every six months, or sooner when your team, product or customer base changes noticeably.
FulcrumGrid Command Center
Track incidents next to your KPIs
FulcrumGrid Command Center keeps incident counts, response times and projects in one place, so you can see whether your severity targets hold up month after month.