Most severity scales ship with five levels and get used at two. The SEV4s pile up unread, and every real argument happens on the SEV1/SEV2 line anyway. A scale nobody applies consistently is worse than a small one everybody does, because it turns the first minute of every incident into a classification debate instead of a fix.
What a Severity Level Actually Decides
Severity is a routing decision, not a description. Before you write any definitions, be clear about what the label changes:
- Who finds out, and how fast. A phone call at 3 a.m. or a Slack message read at 9.
- What customers see. Whether the status page flips to a red banner, a yellow one, or nothing.
- Whether it counts. Whether the minutes land in your uptime figure and your SLA report.
Everything else people try to encode into incident severity levels (how hard the fix is, how many engineers it needs, whose fault it was) is a separate question that gets answered after the page fires. Effort is not severity. A one-line config change that restores checkout is a Sev 1 fixed quickly, not a Sev 3.
Why Five Levels Collapse Into Two
The five-level scales are borrowed from enterprise service management, where they do real work: a 200-person org needs SEV3 and SEV4 to sort a ticket queue across several teams with different response contracts.
A team of four has no queue to sort. It has one question at 2 a.m., and the question is binary: do I get up?
Adding levels below that line doesn’t add precision, it adds an argument. We’ve watched teams spend longer deciding whether something was a SEV2 or a SEV3 than the outage itself lasted. The levels below “wake someone” all resolve to the same behaviour, which is “look at it during business hours”, so they may as well be one level.
The Scale That Survives Contact
Two levels that change behaviour, plus a lane for things that change nothing:
| Level | What it means | Who hears about it | Status page |
|---|---|---|---|
| Critical | Customers can’t do the main thing your site exists for | Whoever is awake, immediately, by phone or push | Red: service down |
| Degraded | The site works, but something meaningful is broken or slow | The team channel, now; a human at the next reasonable hour | Yellow: partial impact |
| Notify only | Worth knowing, changes nothing about today | A notification, no page, no banner | Nothing |
The notify-only lane is the one people skip, and it’s the one that keeps the other two honest. Analytics tags going missing, a staging certificate approaching expiry, a scraper hammering a search endpoint: all worth a message, none worth a status. Without somewhere to put them, they get filed as Degraded, and Degraded stops meaning anything. That is alert fatigue arriving through the front door with a severity label on it.
Write the Definitions as Symptoms
Adjectives are where severity scales go to die. “Major impact to business operations” cannot be applied at 3 a.m. by someone who has been awake for ninety seconds. Symptoms can.
Write your definitions as things a person can observe in under a minute:
Critical
- The site doesn’t load, or loads an error page
- Checkout, login, or signup fails
- Payments are being taken and orders aren’t being created
- Customer data is exposed or being lost
Degraded
- One non-essential page or feature is broken
- Pages load but take more than a few seconds
- A scheduled job hasn’t run and nothing has broken yet
- One region or one browser is affected, everywhere else is fine
Notify only
- A tracking script or third-party embed is missing
- A certificate expires in more than a week
- A dependency you don’t serve traffic through is having a bad day
Yours will differ, and that’s the point: the list is your product, not a template. An e-commerce store puts checkout at the top. A publisher puts the article page there and probably doesn’t have a checkout at all.
Let the Monitor Set It Where It Can
A surprising amount of this can be decided before a human is involved, because the check that noticed already knows what it was checking.
That’s how severity works in FlareWarden. An incident carries one of two levels, and each does something specific: Critical moves the monitor to DOWN, sends notifications immediately, and counts against uptime. Degraded moves it to DEGRADED, notifies subscribers, and is tracked separately from full outages, so a slow afternoon never gets averaged into your outage record. Content checks add the third lane directly: a check can be set to Notify Only, which sends the message without touching monitor status at all. You can also open an incident by hand at either level when you know about something the monitors don’t, which is most partial outages. The details are in the incidents documentation.
Two levels wasn’t a shortcut. It’s the same conclusion as above, built into the product: a level that doesn’t change what happens next is a level that will be argued about instead of used.
Common Misreadings
Severity is not priority. Severity describes the customer’s experience right now. Priority describes what your team does about it, and the two come apart all the time. A Degraded incident on the page that drives all your signups may well get worked before a Critical one on an internal admin tool.
Severity can change. Most incidents start ambiguous. Start high, downgrade when you know more, and say so in the update. The downgrade is good news and reads like competence. Guessing low and upgrading twenty minutes later reads like you weren’t watching.
Degraded is not a lesser outage. It’s a different thing. “Available but wrong” is its own category, and treating it as service degradation rather than a small outage is what stops you from quietly rounding real problems down to zero.
One level is fine for a while. If you’re one person with one site, “the site is broken” is a complete severity model. Add Degraded the first time you get woken by something that could have waited until morning.
Where the Scale Meets Customers
Incident severity levels are the one piece of internal vocabulary your customers end up reading, even when they never see the word itself. The moment severity becomes public, it stops being an internal filing convention. A red banner and a yellow one make different promises, and customers remember which one you used. Pick the level your customers would pick if they could see what you can see.
Practically, that means the status page should be driven by severity automatically rather than by whoever remembers to update it. A status page that reflects Critical and Degraded on its own is one fewer thing to do while you’re busy, and one fewer way to publish something that contradicts what people are experiencing. Once you have the level, the incident runbook for that level should be short enough to actually follow.
Key Takeaways
- Severity routes, it doesn’t describe. The only levels worth having are ones that change who gets woken, what customers see, or whether the minutes count.
- Two levels plus notify-only beats five. Below “wake someone”, every level produces the same behaviour, so extra levels buy arguments rather than precision.
- Write symptoms, not adjectives. “Checkout fails” can be applied in ten seconds at 3 a.m. “Major business impact” cannot.
- Give the harmless things a home. Without a notify-only lane, low-stakes alerts get filed as Degraded and drain the meaning out of it.
- Start high and downgrade. Downgrading with an explanation builds trust. Upgrading twice looks like you weren’t paying attention.
- Severity is not priority. What customers are experiencing and what you work on next are two separate calls, and they legitimately disagree.
Want incidents that arrive already classified, with the status page following along? Start monitoring free with FlareWarden — Critical and Degraded severities, 15 monitors, no credit card required.