Defining Incident Severity Levels: A Four-Tier Template

Define levels by what customers experience, not by which system failed. A database issue that nobody notices isn't SEV1, and a small bug in checkout might be. Starting definitions:

• SEV1: the product is down or unusable for most customers, data is being lost or exposed, or a critical money-handling flow is failing. Respond immediately, all hands as needed.
• SEV2: a major feature is broken or slow for many customers, or a significant customer is blocked with no workaround. Respond immediately during staffed hours and page on-call out of hours.
• SEV3: a limited group is affected, or a workaround exists. Handle within the working day without paging.
• SEV4: cosmetic or low-impact problems with no urgency. Put in the backlog.

Say your team decides SEV1 acknowledges within 15 minutes and SEV2 within 30. Those are examples; choose numbers you can actually meet with your staffing, and write them next to each level.

A severity level is only useful if it changes behavior. For each level, decide these five things up front:

1. Who gets paged and how, including whether it wakes people at night.
2. Whether a dedicated incident channel and commander are required.
3. How often customers and internal stakeholders receive updates.
4. Whether a postmortem is required, such as for every SEV1 and any repeat SEV2.
5. Whether leadership, support or legal is notified.

Tie this to your response process in the incident response plan template and the review format in the blameless postmortem template.

Make it easy to declare an incident and hard to hesitate. Anyone in the company should be able to raise one, and the first responder assigns an initial level using the definitions. The incident commander owns the level after that.

Two rules reduce arguments. First, when unsure between two levels, pick the higher one and revisit within a set time, because downgrading is cheap and a slow response isn't. Second, log every change with a reason, so the review can see how understanding evolved. Escalate when impact grows, when the fix is taking longer than expected, or when a key customer is involved. Downgrade when impact is contained and only cleanup remains.

Data exposure doesn't always look like an outage, so define it separately. A common approach: any confirmed or strongly suspected unauthorized access to customer data starts at SEV1 until scoped, regardless of visible impact. That triggers the security branch of your plan, including evidence preservation and a call to counsel about notification duties, which vary by jurisdiction and contract.

Row-level isolation failures in multi-tenant databases fall into this bucket too. If one customer can read another's rows, treat it as top severity even if nobody has complained. Details on how such policies are written are in Supabase row level security examples.

Watch for these patterns:

• Too many levels. Five or six tiers invite debates about the boundary; four is enough.
• Definitions based on internal metrics like CPU instead of customer impact.
• Everything is SEV1, so the label stops meaning anything and people stop reacting.
• Levels that never change response. If SEV2 and SEV3 are handled the same way, merge them.
• No review of past incidents against the definitions, so the scheme drifts from reality.

Once a quarter, look at the last several incidents and ask whether the assigned level matched the impact. Adjust the wording, not the people. Products like incident.io and PagerDuty can bake severity into routing and channel creation, which helps once your definitions have settled.