Is There A Purpose In Assigning Incident Severity?

In early January 2025, I was reviewing some recent incidents. (It’s something I genuinely enjoy; as a business leader, I find that incidents give you the most honest view of how things are really going.)

While reviewing, something stood out: many incidents didn’t have a severity assigned.

My immediate reaction? Hurrah! Two improvement opportunities:

1. I should sit down with the team and remind them about our incident response protocol—and why severity matters.
2. We should update our internal tooling to make “severity” a mandatory field.

But then… I hit a wall.

The Unexpected Dilemma: It Didn’t Really Matter

I looked more closely at those incidents with no severity labels. I wanted to gather evidence to support the push for using severity levels. But here’s the kicker:

• The team responded to all of them with urgency.
• Communication with me and with customers was solid.
• Everyone worked methodically to restore service.

There was nothing—no gap, no delay, no misalignment—that I could attribute to missing severity level.

Fast forward three months and several more incidents later: I still can’t find a single compelling reason to enforce mandatory severity tags in our process.

And it’s bothering me. So… I’m writing this post. Maybe partly to find closure. But mostly, to ask: What value do you see in assigning severity levels to incidents?

Important Context

For 15 years, I’ve used severity levels religiously. I’ve:

• Raised every incident with a severity level.
• Spent hours updating availability KPI dashboards and various severity related graphs.
• Update incident process flows for each severity level (not sure if anyone read them).

Now I find myself questioning whether any of that mattered when it came to actually resolving the incident.

My current experience is all happening in the context of a small startup (the observations are context specific):

• Our engineers know most of the system inside out.
• Everyone is closely aligned with business goals.
• There’s very little “process baggage” to deal with.

But even when I think back to my experiences at larger, mission-critical enterprises, I still struggle to justify severity as useful in improving the actual response.

Let’s be real: If a network firewall is introducing latency and an engineer is already looking at it, calling it a Sev 1 won’t magically make them work faster, improve their skills or increase their desire to fix it. (I know it's always network!)

What it’d probably do is to get many more people involved who will need to get attention of the person who is fixing the issue to explain to them what is going on. Don’t get me wrong, there are many cases that multiple people are required, but there are also cases that the individual looking into the issue can fix it.

So, Should We Reintroduce Severity at Uptime Labs?

Here’s how I’ve been thinking through it:

1. What’s the intended outcome of assigning severity levels?

• Help everyone prioritise: If it’s a Sev 1 or Sev 2, it signals permission to drop everything (even sleep at 2am) and focus on the incident. (Small challenge: what to prioritise if there are two Sev 1s at once?)
• Trigger a “martial law” effect: Certain rules can be temporarily relaxed. e.g., bypassing security steps or making changes without a formal change request.
• Efficient communication: Severity label on its own communicates multiple point including but not limited to:

In short:for us severity is meant to create focus, space, alignment, and reduce friction, all in service of faster recovery.

1. So what happens when we don’t assign severity? Do we lose anything?

In our case? Nothing.

Every time an incident was flagged, the on-call responder jumped in. They quickly escalated, pulled others in when needed and because we’re small we don’t need the “martial law” effect —we don’t have many rigid processes to suspend.

We’ve got a business comms channel that is always on.; with the customer success and leadership teams always watching, staying aligned, and ready to create space for incident handlers.

I’ve also seen no correlation between recovery time and severity labels. This matches what we observed in our Incident Groundhog Day study last year.

1. My gut tells me: the less we have to do during an incident, the better.

So if we can function without assigning severity, I’d call that a win.

Observing How Teams Work Without Incident Severity

The realisation that hit me — there is a goldmine hidden in observing how people actually work and the choices they make.

In our case, the team chose to drop severity, even though we had a legitimate reason (a process document!) to keep it.

And the system didn’t fall apart. In fact, it may have improved.

Which leads me to wonder: Are we enforcing inefficiency just because it’s written down somewhere?

To be clear, I’m not saying every team should stop using severity levels. That’s not my call, and honestly, there are plenty of great resources out there that examine utility of severity labels (I’ve linked some at the end of this post).

What I am saying is this: It’s worth asking whether severity levels are actually producing the outcomes your organisation expects. Because if they’re not… maybe it’s time to rethink why we’re using them.

Resources

• The Negotiability of “Severity” Levels
• Against Incident Severities and in Favor of Incident Types
• SREcon24 Americas - What Is Incident Severity, but a Lie Agreed Upon?
• Incident SEV scales are a waste of time