Severity Classification Matrix: Defining P1 to P4 Incidents

Why you need a severity matrix

Without agreed definitions, every incident begins with an argument about how bad it is. One engineer calls a partial slowdown a disaster. Another treats a data exposure as a minor bug. The wrong people are woken, or the right people are not. Leadership cannot judge whether the reaction was proportionate, because there is no standard to compare it to.

A severity matrix settles this in advance. It is a short document that says what each level means and what happens when an incident reaches it. It is one of the foundations of our SRE and incident response service and underpins the incident management process.

What good looks like

• Objective criteria. Two engineers reading the same facts reach the same level.
• Impact-based. Defined by effect on customers, data and the business.
• Actionable. Each level has a response: who is notified, whether the full incident roles are used, update cadence and target response.
• Realistic. Targets match who is actually available at the hour in question.
• Changeable. Anyone can raise severity, and the commander can lower it.
• Short. One page that people can recall under stress.

An example matrix

The table below is an illustrative starting shape, not a recommended set of numbers. Percentages, targets and cadences are for you to set from your own business context.

You will notice there are no response-time numbers in the table. That is deliberate. The right numbers depend on your coverage model, contracts and team size. We fill them in together, and we mark which are internal goals and which are customer commitments.

Writing criteria that survive stress

Vague words such as “major” or “significant” cause arguments. We replace them with observable conditions wherever possible:

• Share of requests failing or exceeding the latency objective, taken from your SLO dashboards.
• Whether a revenue-critical flow such as checkout or sign-in is down.
• Whether customer data may have been lost, corrupted or exposed.
• Whether a legal, contractual or regulatory obligation is at risk.
• Whether a workaround exists and how painful it is.

Security and data events deserve explicit treatment. Suspected data exposure usually deserves a high level regardless of how many users noticed, because the harm is not visible in error rates.

Connecting the matrix to tooling

A matrix on a wiki page is read once. A matrix wired into tools is used every day. We configure it so severity drives behaviour:

# Alertmanager: map alert severity labels to paging behaviour
route:
  receiver: ticket-queue
  routes:
    - matchers: [severity="p1"]
      receiver: pager-critical
      repeat_interval: 15m
    - matchers: [severity="p2"]
      receiver: pager-high
      repeat_interval: 1h
    - matchers: [severity=~"p3|p4"]
      receiver: ticket-queue

The repeat_interval values here are examples of the mechanism, not recommendations. In your paging tool, priorities map to escalation policies, so a P1 notifies a wider chain faster than a P2. See the on-call rotation setup for how those policies are built.

Decisions and trade-offs

Alert severity versus incident severity. An alert’s configured severity is a guess made at design time. The incident’s severity is a judgement made with real facts. Allow the two to differ, and review alerts that are frequently reclassified.

Customer-facing commitments. If your contracts promise response times, those become SLAs with consequences. Keep the internal matrix stricter than anything promised externally, and be honest about the hours you can staff. Overpromising on paper is worse than a smaller, truthful commitment.

Upgrade on doubt. Teams that fear “crying wolf” under-classify. We encourage the opposite: escalate when unsure and accept the occasional downgrade.

When a matrix is premature. A team that has had two incidents in a year does not need elaborate classification. A three-line rule of thumb is enough until incident volume justifies more.

Common failure modes

• Severity by seniority. Whoever shouts loudest sets the level.
• Too many levels. Nobody remembers the difference between P3 and P4.
• Targets nobody can meet. Missed targets become routine and meaningless.
• Never revisited. Business priorities change; the matrix must too.
• Ignoring security. Data exposure treated as a performance issue.

Worked example: classifying a real-sounding incident

Imagine the checkout page returns errors for a subset of customers, while the rest of the product works. The matrix asks: is a core journey broken, how many users are affected, and is there a workaround? A broken core journey for a meaningful share of users with no workaround points to the top severity tier. If a workaround exists and the share is small, a lower tier applies.

The important rule is that when the facts are unclear, the responder picks the higher severity and downgrades later. Raising a false alarm costs a few minutes. Under-classifying a real outage costs trust.

Reclassification

Severity is not fixed at declaration. We define who can change it (the incident commander), how the change is announced in the channel, and how timers reset. A downgrade should be recorded with a reason, because it is the first thing reviewers look at in the post-mortem.

Aligning with contracts

If you have customer-facing commitments, map the internal tiers to them carefully, and have someone from legal or customer success confirm the wording. We do not invent figures for you.

Delivery and handover

You receive the one-page matrix, a longer reference with examples drawn from your own incident history, the configured priorities in your paging tool, and a short briefing for engineers, support and leadership. We review it after the first month of use and again each quarter. For teams wanting round-the-clock enforcement, the same matrix underpins our Managed DevOps coverage.

How to tell it is working

Check how often incidents are reclassified, whether classification disagreements have dropped, whether response matched the level, and whether stakeholders say they know what to expect. If P1 genuinely means all hands and P3 genuinely means “see you tomorrow”, the matrix is doing its work. To build yours, contact us.

References

• Managing Incidents, Google SRE book
• Incident Response, Google SRE workbook
• Incident Response Recommendations and Considerations for Cybersecurity Risk Management, NIST SP 800-61 Rev. 3