Photo by K. Mitch Hodge on Unsplash
A status page with vague or inconsistent severity levels is worse than no status page at all. If every incident gets labeled "degraded performance" regardless of whether it's a typo in a footer or a full database outage, customers stop trusting your updates and start opening support tickets instead. Getting status page incident severity levels right is one of the highest-leverage, lowest-effort improvements a team can make to incident communication.
This guide covers how severity levels work, how the major tools implement them, and how to build a framework your team will actually follow under pressure.
Understanding Incident Severity Levels
Severity levels are a classification system that describes how badly an incident affects your users or systems. They exist for one simple reason: not every problem deserves the same response, the same communication, or the same urgency. A payment processing outage and a slow-loading avatar image are both "incidents" in the loosest sense, but treating them the same way wastes engineering time and confuses customers.
Most teams define severity along a scale, typically four to five levels, ranging from complete outage down to cosmetic issue. The label matters less than the consistency behind it. What actually matters is that a SEV-1 always means the same thing to every engineer, every time, regardless of who's on call.
Impact on customer communication. Severity level determines what you say, how often you say it, and where you say it. A SEV-1 outage justifies proactive banner notifications, email alerts to affected customers, and updates every 15-30 minutes. A SEV-4 cosmetic bug doesn't need a status page entry at all in most cases. Getting this mapping wrong in either direction erodes trust: over-communicate minor issues and customers tune out your alerts; under-communicate major ones and customers feel blindsided.
Impact on response time. Severity levels typically map directly to SLA response times. A SEV-1 might require acknowledgment within 5 minutes and an all-hands response. A SEV-3 might tolerate a next-business-day fix. This mapping is what makes on-call rotations sustainable. If you want a deeper look at building sustainable on-call systems around these response tiers, see our guide on on-call scheduling best practices for small teams.
Common misconceptions. The biggest misconception is that severity equals technical complexity. A one-line config typo that takes down your entire API is a SEV-1, even though the fix takes two minutes. Conversely, a deep, gnarly bug in an internal analytics pipeline that no customer notices is not a SEV-1, no matter how hard it is to diagnose. Severity is about customer and business impact, not engineering difficulty. Another common mistake: treating severity as a fixed label instead of a dynamic assessment. Incidents often start as one severity and escalate or de-escalate as more information comes in.
Standard Severity Level Frameworks
Most status page incident severity levels fall into a four-tier structure, sometimes expanded to five when teams want a dedicated "informational" or "maintenance" tier.
CRITICAL / SEV-1: Complete service outages. The core product is unavailable to all or nearly all users. Examples: the API returns 500s across the board, the login system is down, payments fail for every transaction. Response is immediate, all-hands, with status page updates every 15-30 minutes until resolution.
HIGH / SEV-2: Major functionality impaired. A significant feature is broken or severely degraded, but the core product still works for most users. Examples: search returns incomplete results, a major integration (like Stripe or SSO) is failing intermittently, uploads fail for 20% of requests. Response is urgent, usually within 15-30 minutes, with status updates every 30-60 minutes.
MEDIUM / SEV-3: Partial service degradation. A subset of users or a non-critical feature is affected. Examples: slow page loads for users in one region, a reporting dashboard showing stale data, elevated error rates that haven't triggered customer complaints yet. Response happens during business hours, updates are less frequent, and status page posts may be optional depending on visibility.
LOW / SEV-4: Minor issues and cosmetic problems. Examples: a broken image, a typo in an email template, a UI element misaligned on one browser. These rarely warrant a status page entry at all. They're tracked as bugs, not incidents.
Mapping across industries. A fintech company might treat any payment-related issue as an automatic SEV-1 regardless of how many users are affected, because of compliance and trust implications. A SaaS analytics tool might reserve SEV-1 exclusively for full outages and treat data delays as SEV-2 even if they affect every customer, because stale data is annoying but not catastrophic. E-commerce platforms often add a special "checkout" severity tier that overrides normal impact-based scoring during high-traffic periods like Black Friday.
Real-world examples. A CDN provider going down that breaks image loading site-wide: SEV-1. A single API endpoint returning errors for 5% of requests: SEV-2. A background job queue running 30 minutes behind schedule with no customer-visible impact yet: SEV-3. A dashboard chart rendering with the wrong color scheme: SEV-4.
How Different Status Page Tools Handle Severity Levels
The concept of status page incident severity levels is universal, but implementation varies a lot between tools. If you're evaluating platforms, understanding these differences matters more than the marketing copy suggests.
Atlassian Statuspage. Statuspage uses impact levels rather than strict severity numbers: None, Minor, Major, and Critical. Each maps to a color (green, yellow, orange, red) that displays on the public status page. It's simple and customer-facing, but it's fairly rigid. You can't easily add custom tiers without workarounds, and the impact levels are tied more to public messaging than internal triage, meaning teams often run a separate internal severity system alongside it.
Incident.io. Incident.io treats severity as a fully configurable field, with organizations free to define their own labels, descriptions, and even automation rules tied to each level (like auto-inviting responders or auto-creating a Slack channel for SEV-1s). This is one of its stronger differentiators: severity isn't just a label, it's a trigger for workflow automation.
PagerDuty. PagerDuty doesn't use "severity" as its primary vocabulary. Instead it uses "urgency" (high/low) at the incident level and "priority" (P1-P5) as a separate, often manually assigned field. This split confuses teams migrating from other tools, because urgency drives notification behavior while priority is more of a triage/reporting label. Teams need to explicitly map their severity framework onto PagerDuty's urgency and priority fields rather than assuming a 1:1 match.
Opsgenie. Opsgenie uses a priority system (P1-P5) similar to PagerDuty, with priority driving escalation policies and notification rules. Opsgenie's mapping is more configurable than PagerDuty's at the alert level, letting teams set rules that assign priority based on alert source, tags, or content, which is useful for automating initial severity assignment before a human ever looks at it.
Custom frameworks. Many teams, especially past a certain size, abandon vendor-default severity schemes entirely and build their own, often documented in an internal runbook and enforced through templates in their incident management tool. This gives maximum flexibility but requires discipline to keep definitions from drifting between teams.
Comparison Table
| Tool | Terminology | Default Levels | Customizable? | Ties to Automation |
|---|---|---|---|---|
| Atlassian Statuspage | Impact | None, Minor, Major, Critical | Limited | Minimal |
| Incident.io | Severity | Fully custom | Yes, fully | Strong (workflows per severity) |
| PagerDuty | Urgency + Priority | High/Low urgency, P1-P5 priority | Partial | Strong (notification rules) |
| Opsgenie | Priority | P1-P5 | Yes, via rules | Strong (routing rules) |
No tool here is objectively "best" for severity handling. Statuspage wins on public-facing simplicity, incident.io wins on internal flexibility, and PagerDuty/Opsgenie win on tying severity into actual paging and escalation behavior. If your team already has a strong internal severity framework, look for the tool that maps to it with the least friction rather than the one with the most default options.
Best Practices for Defining Your Severity Levels
Assess customer impact separately from system impact. A database running at 90% CPU is a system-level concern. It only becomes a severity-worthy incident when it starts causing timeouts or errors that customers experience. Build your severity criteria around observable customer impact first, with system health metrics as supporting evidence, not the primary trigger.
Set explicit SLA response times per level. Document exactly what "immediate response" means in minutes, not vibes. A common pattern: SEV-1 acknowledge in 5 minutes, mitigate in 30; SEV-2 acknowledge in 15 minutes, mitigate in 2 hours; SEV-3 acknowledge within a business day. These numbers should tie back to whatever uptime commitments you've made. If you haven't nailed down what your uptime targets actually mean in practice, our breakdown of uptime SLAs and the nines table is worth reading alongside this.
Build a decision tree, not a paragraph. Prose descriptions of severity levels get interpreted differently by every engineer. A decision tree with concrete yes/no branches ("Is the core product unusable for more than 10% of users? Yes, go to SEV-1 branch. No, is a major feature broken for any users? ...") produces far more consistent classification, especially from newer team members or people paged at 3 a.m.
Watch for severity creep. Two forms of drift happen constantly. First, engineers under pressure inflate severity to get more resources or attention ("everything is a SEV-1"), which devalues the label over time. Second, the opposite happens after a few false alarms, where real SEV-1s get downgraded to avoid "crying wolf," which delays proper response. Regular retrospective review of severity assignments, not just incident resolution, catches both patterns.
Document criteria in your runbooks. Severity definitions shouldn't live in a wiki page nobody reads. They belong directly in the incident response runbook your team actually opens during an incident, alongside escalation paths and communication templates. Our incident response runbook templates guide includes examples of how to embed severity criteria directly into actionable runbook steps.
Test definitions against past incidents. Take your last 10-20 incidents and re-classify them using your new severity framework. If multiple people on the team would classify the same incident differently, your criteria are still too vague. This exercise usually surfaces edge cases (partial outages, regional issues, third-party dependency failures) that your first draft didn't account for.
Communicating Severity to Customers
Transparency builds trust, vagueness destroys it. Customers don't need a play-by-play of your infrastructure, but they do need honest signal about how bad something is and roughly when it'll be fixed. A status page that says "we are aware of an issue" for six hours straight, regardless of actual severity, trains customers to distrust every future update.
Scale communication frequency to severity. SEV-1 incidents deserve updates every 15-30 minutes, even if the update is just "still investigating, next update in 30 minutes." SEV-2 can be less frequent. SEV-3 and below often don't need public updates at all unless a customer specifically asks. Matching cadence to severity keeps your status page credible instead of either silent during real emergencies or noisy during minor blips.
What not to share. Avoid naming specific customers affected, internal system architecture details that could be a security risk, unconfirmed root causes ("we think it might be X" often turns out wrong and requires embarrassing corrections), and blame directed at third-party vendors before you're certain. Stick to: what's affected, who's affected (in general terms), what you're doing, and when the next update will come.
Legal and compliance considerations. Regulated industries (finance, healthcare, anything under SOC 2 or ISO 27001) often have contractual notification requirements tied to severity level, meaning your public severity classification can have real legal weight. If a SEV-1 triggers a customer notification clause in your contracts, your internal and external severity labels need to be tightly aligned, and legal should review your severity-to-disclosure mapping at least annually.
Good vs. poor examples. A poor update: "We're experiencing some issues, working on it." A good update: "Users in the EU region are experiencing elevated error rates (approximately 15% of requests) when uploading files. Our team has identified the cause and is deploying a fix. Next update in 30 minutes." The second example signals severity through specifics without requiring the word "severity" to appear anywhere.
Automating Severity Assignment and Escalation
Alert rules can pre-assign initial severity. Most modern monitoring and alerting tools let you tag alerts with a starting severity based on thresholds (error rate above X%, latency above Y ms, health check failures across Z% of instances). This gives responders a starting point rather than a blank slate. For this to work well, your monitoring needs to actually be watching the right things. Teams that assign severity confidently but miss entire failure modes usually have gaps in coverage, which is worth auditing using our guide on finding and fixing monitoring blind spots in distributed systems.
Integration with on-call systems. Severity should directly drive who gets paged and how. A SEV-1 might page the primary and secondary on-call simultaneously plus notify an engineering manager. A SEV-3 might just create a ticket for business-hours triage. This mapping needs to live in your paging tool's escalation policies, not just in a document someone reads after the fact.
Automated escalation workflows. If a SEV-2 incident hasn't been acknowledged within its SLA window, automation should escalate it, either to a secondary responder or by bumping the severity itself. This prevents incidents from languishing because the wrong person was paged or someone missed a notification.
Machine learning approaches. Some newer platforms attempt to auto-classify severity using historical incident data, correlating current symptoms (error rate patterns, affected endpoints, time of day, customer segment impacted) against past incidents to suggest a severity level. This works reasonably well for common, recurring failure patterns but tends to underperform on novel incidents, which are exactly the ones where correct classification matters most.
When to override automation. Automation should suggest, not dictate, especially in the first few minutes of an incident when data is incomplete. A responder who sees additional context, like a major customer explicitly reporting an outage, or a correlated incident with a third-party vendor, should be able to override the automated severity without friction or approval gates.
Preventing false severity classifications. The most common failure mode is a monitoring blind spot causing a real SEV-1 to be initially flagged as lower severity because the alert that would have caught it never fired. The second most common is alert noise causing genuine signals to get buried, which ties directly into broader alert fatigue problems. Our guide on alert fatigue reduction strategies for small teams covers how to tune alerting so severity signals stay meaningful instead of getting lost in noise.
Tools like Uptiqr help here by keeping monitoring and status communication tightly connected, so severity assignment during an incident is based on the same data your team is already watching, rather than requiring a separate manual assessment step. If you're setting up a status page and want severity levels that map cleanly to your monitoring checks, it's worth looking at how Uptiqr's features or pricing fit your team's setup.
FAQ
What's the difference between incident severity and priority? Severity measures impact, how bad the incident actually is for customers or systems. Priority measures urgency of response relative to other work, which can be influenced by severity but also by business context (a low-severity issue affecting your biggest customer might get bumped in priority). Some tools conflate the two; it's worth keeping them conceptually separate even if your tool doesn't force the distinction.
Should we use 3, 4, or 5 severity levels? Four levels (Critical, High, Medium, Low) works for most teams. Three levels is fine for very small teams where the middle tiers rarely get used differently. Five levels usually means someone added a level to handle an edge case rather than because the extra granularity improves decision-making; it often adds confusion instead. Start with four and only add more if you find real, recurring gaps.
How do we handle severity changes during an incident? Severity should be re-evaluated at every major update, not fixed at incident creation. Document the change and the reason ("upgraded to SEV-1 after confirming payment processing is affected") both internally and, when appropriate, on the public status page. Customers generally respond well to visible escalation because it signals you're actively assessing the situation rather than guessing once and moving on.
What's the most common mistake teams make with severity levels? Treating severity criteria as static documentation that nobody revisits. Definitions get written once during onboarding, then never updated as the product, customer base, or infrastructure changes. Two years later, half the team is using outdated criteria and the other half is improvising.
How often should we review and update our severity definitions? At minimum, once a year, plus after any incident where classification caused confusion or delay. Many teams fold this into quarterly postmortem reviews, using real incidents as test cases against current definitions. Our postmortem templates guide includes a section for capturing whether severity was assigned correctly, which is a good habit to build into every retro regardless of incident size.