Glossary
Incident severity
Incident severity is a ranking of how bad an incident is, such as SEV1 to SEV3, used to decide who is woken and how fast.
Also called Severity levels, Sev levels, SEV1, SEV2, P1.
Severity is a small ordered scale — SEV1 through SEV3 or 4, or P1 through P4 — attached to an incident to say how bad it is. Its entire purpose is to drive different behaviour: who gets woken, how fast, whether customers are told, whether the work stops until it is fixed. A severity that changes nothing about the response is a label rather than a level.
Definitions should be written in terms of customer impact, not system internals, and they should be short enough to apply at 3am under pressure. Something close to: SEV1, customers cannot use the product, wake whoever is needed. SEV2, significant impairment or a subset of customers badly affected, page the on-call. SEV3, degraded or limited impact, handle in hours. The exact wording matters less than that everybody reads it the same way.
Two habits keep the scale honest. Severity should be revisable — starting high and downgrading once the blast radius is understood is much safer than the reverse, and a scale where downgrading feels like an admission will be gamed towards under-declaring. And it should be reviewed occasionally, because severities drift: when everything becomes a SEV2, the level has stopped carrying information and the response it was meant to trigger has quietly stopped happening.
| Level | What it means | Example | Typical response |
|---|---|---|---|
| SEV1 (P1) | Customers cannot use the product, or data is at risk | A full outage, or checkout failing for everyone | Page on-call now, pull in whoever is needed, update customers often |
| SEV2 (P2) | A major feature is broken, or some customers are badly affected | Logins failing in one region, or one payment method failing | Page on-call, post a status update |
| SEV3 (P3) | Degraded or limited impact, with a workaround | A slow dashboard, or one report failing to export | Fix during working hours |
| SEV4 (P4) | Cosmetic, or internal only | A typo, or an internal tool running slowly | Add to the backlog |
Questions
What are incident severity levels?
Incident severity levels are an ordered scale, usually SEV1 to SEV3 or SEV4, that says how bad an incident is. Each level triggers a different response: who is paged, how fast, and whether customers are told.
What is a SEV1 incident?
A SEV1 is the most severe level: customers cannot use the product, or data or security is at risk. Examples are a full outage or a data breach. It justifies waking people and stopping other work until it is fixed.
What is a SEV2 incident?
A SEV2 is a significant incident that is not a full outage: a major feature is broken, or a subset of customers is badly affected. On-call is paged and a status update is posted, but it does not usually need everyone at once.
Is SEV1 or SEV3 more severe?
SEV1 is more severe. The number goes up as impact goes down, so a SEV1 wakes people and a SEV3 waits for working hours. Some teams add a SEV0 above SEV1 for events that threaten the whole business.
What is the difference between SEV levels and P levels?
They are two naming schemes for the same idea. SEV is the usual name in incident response. P, for priority, comes from IT service management, where priority often combines impact with urgency. Pick one, and write down what each number means.
In Uptimely
Uptimely incidents carry a severity that you define per project, and notification rules can filter on it — so a Slack channel or an on-call policy can be scoped to critical incidents without silencing the rest.
Uptimely projects start with Critical, Major and Minor severities that you can change or add to, and notification rules can send each level to a different channel.
Start monitoring free →Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.