Incident response severity levels: P1, P2, and P3 explained

A common question in implementation calls is, “Should this be a P1?”

The service is still up, but checkout latency has doubled. Support says several customers are blocked. The on-call engineer sees only one affected region, and nobody yet knows whether the problem is spreading. Engineering, support, and leadership are looking at the same incident through different kinds of impact.

As a solutions engineer, I have found that the hard part is rarely remembering what P1, P2, and P3 mean. It is agreeing on definitions that people can apply with incomplete information.

I think of an incident severity level as a response contract. Based on the impact understood at that moment, it determines who gets paged, who leads, how often the organization communicates, and what follow-up is required. The classification can change as the evidence changes.

Understanding incident response severity levels

Severity, priority, and support levels

Teams often use these terms interchangeably, which creates confusion before an incident even begins.

Severity describes the impact of the incident: what users, data, services, or business operations are affected, and how badly.
Priority describes how urgently the organization should act relative to other work.
Support level usually describes a customer-support entitlement, routing path, or response commitment.

Severity will influence priority, but they are not identical. A visible typo on a high-traffic launch page has little functional impact and may still receive immediate attention. A serious defect in an unused path can have high potential severity while sitting behind a more urgent production outage.

The naming is inconsistent across companies and tools. One organization’s P1 may be another organization’s SEV0. The label matters less than the documented impact criteria and the response it activates.

Why categorize incidents by severity?

During an incident, responders should be investigating and mitigating, not negotiating from scratch about who needs to join or whether customers need an update.

A severity model lets the organization make those decisions ahead of time. When a responder assigns P1, the team should already know:

Which on-call responders and backups are paged
Whether an incident commander is required
Which response roles need owners
How internal and external communication will run
Whether a public status update, leadership notification, or legal review is needed
Which retrospective and follow-up requirements apply

That is the operational value of a severity level: it turns an impact assessment into a known response.

Breaking down incident levels: P1, P2, P3

The table below is an example for a SaaS company using P1 as its highest incident level. It is a starting point, not an industry standard.

Dimension	P1: critical	P2: major	P3: limited
Customer impact	Widespread or affects a critical customer journey	Material but contained to a subset of customers, regions, or functionality	Limited impact; service remains broadly usable
Critical functionality	Unavailable or unsafe to use	Degraded or partially unavailable	Working with a minor degradation
Workaround	None, unsafe, or impractical at scale	Available but costly, manual, or incomplete	Practical and documented
Data and security	Active material risk to confidentiality, integrity, or availability	Contained or credible risk requiring specialist review	No evidence of material data or security risk
Trajectory	Impact is growing rapidly or remains unknown	Stable, slowly growing, or bounded	Stable and well understood
Response posture	Immediate coordinated response	Prompt response from the owning teams	Business-hours handling may be appropriate

The person declaring the incident should make the best safe classification available and record the evidence behind it. If the facts fit more than one level, choose the response posture that protects customers while the team verifies scope.

P1 incidents: critical and immediate response

A P1 means the organization needs an immediate, coordinated response. Common examples include:

A customer-facing service is unavailable for most or all users
A critical path such as authentication, checkout, or transaction processing cannot complete
Data is being lost, corrupted, or exposed
A failure is rapidly consuming the error budget across one or more critical services
The team cannot yet bound the impact of a credible high-risk event

The classification should describe impact rather than the component that failed. A database outage is not automatically P1; a failed database used only by an internal test environment may have little production impact. Conversely, a small-looking configuration error can be P1 if it prevents every customer from signing in.

P1 should trigger a known incident process: page the necessary responders, assign command and communications roles, establish an update cadence, and make the current customer impact visible.

P2 incidents: major but contained impact

A P2 has meaningful customer or operational impact without requiring the organization’s highest response posture. Examples might include:

A core feature is unavailable for a subset of customers
One region is degraded while traffic can be shifted safely
A workaround exists but creates significant manual work
Performance has deteriorated enough to affect a critical journey
The incident is consuming an important portion of an SLO budget without threatening it immediately

P2 does not mean “wait until tomorrow.” It should identify the owning responders and the conditions that would promote the incident to P1. Those conditions might include impact spreading to another region, the workaround failing, or evidence of data integrity risk.

P3 incidents: limited and manageable impact

A P3 has limited customer impact, a practical workaround, and a stable scope. The service remains broadly usable.

Some teams handle P3 incidents through a lighter incident process; others route them into normal engineering or support work. That boundary should be explicit. A cosmetic bug or feature request does not become an incident merely because a P3 label exists.

If the issue does enter the incident process, define why: it may need coordination across teams, a customer update, or an operational record even though the immediate impact is small.

Beyond P3: extended levels (P4, P5, SEV levels)

Some organizations add P4 or P5 for low-impact support issues and informational events. Others reserve the incident system for meaningful service impact and send everything else to a ticket backlog.

More levels help only when each one produces a different decision. If P3, P4, and P5 all receive the same owners, response time, and communication, the extra labels add classification work without changing the response.

How P1, P2, and P3 relate to SEV0, SEV1, and SEV2

There is no reliable universal conversion:

Highest-impact convention	Next level	Lower level
P1	P2	P3
P0	P1	P2
SEV0	SEV1	SEV2
SEV1	SEV2	SEV3

In some systems, P explicitly means priority while SEV means severity. In others, teams use the terms as synonyms. When integrating alerting, ticketing, and incident-management tools, map the definitions and response behavior rather than matching numbers.

Teams that use SEV0 usually reserve it for exceptional incidents that need the broadest response. The SEV0 guide explores that operating mode in more detail.

How to define incident severity levels for an SRE team

Start with critical user journeys

List the things customers must be able to do: authenticate, complete checkout, send a message, execute a trade, retrieve data, or receive an alert. A component failure matters because of its effect on one of those journeys, not because the component has an impressive name.

For each journey, ask:

What does complete failure look like?
What does material degradation look like?
How many customers or transactions are affected?
Does a safe workaround exist?
Could the incident compromise data or create irreversible effects?
How quickly could the impact grow?

This gives responders observable criteria instead of adjectives such as “critical,” “major,” and “minor” explaining themselves.

Connect severity to SLOs without making it mechanical

SLO and error-budget data can reduce subjectivity. A service burning a large portion of its error budget in a short window needs a different response from a slow, low-level burn. Google’s guidance on multiwindow, multi-burn-rate alerts shows how different rates can produce different paging and ticketing behavior.

Tony Holmes, Head of SRE at Affirm, describes aligning severity guidelines with SLO and error-budget consumption so the incident process reflects user impact more consistently.

Burn rate is still one input. Low-traffic systems can produce noisy ratios, and an active security or data-integrity incident may demand a high-severity response before an availability SLO moves.

Test the matrix against real incidents

Take ten to twenty incidents from the last year and classify them using the proposed definitions. If experienced responders repeatedly disagree, the criteria are too vague or depend on information that is unavailable during triage.

Review the disagreements with engineering, support, security, and customer-facing teams. They see different parts of the impact. The goal is not perfect historical agreement; it is a model people can apply quickly and explain later.

Escalation paths and communication protocols

Severity should activate a response contract. Here is an illustrative starting point:

Response decision	P1	P2	P3
Paging	Primary and backup responders immediately	Owning on-call teams promptly	Team-defined; may wait for business hours
Leadership	Notify according to explicit impact triggers	Notify when impact or duration warrants it	Usually unnecessary
Incident roles	Incident commander and communications lead assigned	Incident commander assigned when coordination spans teams	Lightweight owner may be sufficient
Customer communication	Assess public status communication immediately	Communicate to affected audiences on a defined cadence	Targeted communication if needed
Follow-up	Retrospective and tracked actions expected	Based on impact, duration, or learning value	Only when the event exposes a meaningful gap

These are internal operating targets, not promises to customers. The exact timing should reflect the company’s coverage model, customer commitments, and incident history.

Escalation should also account for expertise and authority. A responder may need a database owner, security lead, executive decision-maker, or external provider even when the current severity remains unchanged. The incident response playbook guide explains how to encode those coordination decisions without pretending every incident will follow the same script.

SLAs, metrics, and KPIs for incident support

Severity often influences several different clocks. Keep them separate:

Acknowledgement target: how quickly someone confirms ownership
Mobilization target: how quickly the required responders and roles are active
Communication cadence: when the next internal or external update is due
Customer SLA: a contractual commitment, which may use different terms and scopes
Recovery objective: an internal target for restoring a service or business process

Avoid publishing generic resolution times for P1, P2, and P3. A data-integrity incident may require careful recovery even after customer impact stops, while a broad outage may be mitigated quickly. The appropriate target comes from the service and contract, not the label alone.

To evaluate the classification system itself, I would track:

Time from declaration to initial severity
How often incidents are upgraded or downgraded
Whether reassignment happens promptly when impact changes
Time to assemble the responders required by the level
Incidents where the assigned severity and eventual customer impact diverged
Teams or services that consistently overclassify or underclassify

These measures reveal ambiguity in the operating model. They should improve the process, not grade individual responders. The incident response metrics guide covers the broader measurement system.

Best practices for defining and managing incident levels

Make classification provisional

Early incident information is incomplete. Put the initial severity, evidence, and next reassessment time in the incident record. Changing the level later should be routine.

Define promotion and demotion triggers

For each level, document what would move the incident up or down: an additional region failing, the workaround becoming unsafe, customer impact crossing a threshold, or error-budget burn returning to normal.

Keep the decision small

Responders should not complete a long questionnaire before declaring an incident. Use a few observable dimensions and allow unknown values. The process can gather richer information after the response starts.

Practice with engineering and support

Run short calibration exercises using past incidents and ambiguous scenarios. If support sees a customer emergency while engineering sees a small error rate, the discussion should happen during training rather than in the incident channel.

Review definitions after incidents

When the response felt disproportionate, ask whether the classification was wrong, the response contract was wrong, or the impact changed. Those are different problems and lead to different fixes.

Common mistakes organizations make

Classifying infrastructure instead of impact: “The database is down” is a symptom; the severity depends on what that database prevents users from doing.
Confusing severity with priority: impact and response order often align, but they answer different questions.
Using revenue as the only impact: trust, safety, data integrity, contractual obligations, and internal operations may matter before revenue is measurable.
Creating too many levels: additional precision is useful only when it changes the response.
Refusing to reclassify: the initial label should not become a position the team has to defend.
Turning every defect into an incident: low-impact backlog work needs ownership, but not necessarily incident command.
Penalizing responders for choosing a safer posture: fear of “calling a P1” encourages dangerous delay.
Leaving tools with incompatible mappings: P1 in one platform may silently become SEV1 or priority 1 somewhere else.

Comparing industry standards and frameworks

There is no universal P1/P2/P3 or SEV0/SEV1/SEV2 standard.

IT service-management practices commonly combine impact and urgency to determine priority. Organizations still define their own thresholds and response commitments.
SRE practices can use critical journeys, SLOs, and error-budget burn to connect technical signals with user impact.
Cybersecurity response needs additional dimensions such as confidentiality, integrity, evidence handling, and recoverability. NIST’s current incident-response recommendations provide a risk-management framework, not a SaaS severity table.
Internal company schemes encode the services, customers, regulations, and operating model that actually determine impact.

Borrow useful ideas, then publish one internal source of truth. Responders should not have to remember which external framework a label came from while the service is failing.

Tools and platforms that help manage incident levels

A tool should make the agreed severity model easier to execute. Look for:

Custom severity names and descriptions
Required impact fields that remain quick to complete
Clear mapping between alert priority and incident severity
Workflow triggers when severity is assigned or changed
Paging, role assignment, channel creation, and communication based on level
An audit trail of who changed the severity, when, and why
Reporting that shows severity changes and outcomes over time

In Rootly, severities are configurable and can drive workflows, routing, communication, and reporting. That matters because the software should enforce the response contract the team designed; it should not invent the contract for them.

Frequently asked questions

How should a SaaS company define incident severity levels?

Start with critical customer journeys and define observable thresholds for scope, functionality, workarounds, data or security risk, and trajectory. Then specify the paging, roles, communications, and follow-up each level activates. Test the definitions against past incidents before adopting them.

What is the difference between severity and priority?

Severity describes impact. Priority describes how urgently the organization should act relative to other work. Severity is an important input to priority, but the two can differ.

Are P1 and SEV1 the same?

Not necessarily. Some organizations start with P1 or SEV1; others reserve P0 or SEV0 for the highest level. Compare the underlying definitions and response behavior before mapping labels between tools.

Can incident severity change during a response?

Yes. The initial classification is based on incomplete information. Promote or demote the incident when its scope, customer impact, workaround, or risk changes, and record why.

What should happen when an incident is assigned P1?

The organization’s P1 response contract should start immediately: page the required responders, assign incident command and communications ownership, assess customer communication, and set a reassessment cadence. The exact actions should be documented before the incident occurs.

Severity is a living operational decision

A good severity model gives responders a fast, defensible way to turn incomplete evidence into an appropriate response. It creates shared expectations across engineering, support, security, and leadership while leaving room for the classification to change.

The test is simple: when someone declares a P1, does everyone know what that means for customers and what happens next? If the answer depends on who is on call, the labels need more work.