Severity

Once defects pile up, something has to decide what gets fixed first. The trouble is that whoever files a defect usually feels theirs is the urgent one. So the list holds eighty bugs — defects where the software behaves differently than intended — and all eighty arrived with a note asking for a quick look.

In a list like that, payments not working sits on the same line as a typo in a tooltip. Whoever is fixing works down the list in the order things arrived, and the payment failure twelve rows down gets found three days later. Everyone who tried to upgrade during those three days simply left.

Meetings stalled in the same place. When "this is urgent" meets "that can wait," the only tiebreaker left is volume. Sales brings the problem from the call they just took, engineering picks what is quick to fix, and the defect actually blocking revenue loses to both. The order came out different depending on who happened to be in the room that morning.

Severity moves that judgment out of the room and into a standard. A grade gets assigned purely on what the defect makes unusable and for how many people, and the grade then decides who responds and how fast.

Two things determine the grade: how many users are affected, and whether what they were trying to do is fully blocked or has another route. How long the fix will take, who wrote the feature, and who reported it are all excluded on purpose.

Four levels is the most common arrangement.

1. S1. The service is broadly down, data is being lost, or money and security are involved. Nobody can log in, or a payment is charged twice.
2. S2. A core capability is blocked for many users but a workaround exists. Document sharing fails in one browser and works in the others.
3. S3. Something is annoying but the task can still be completed. A list doesn't sort newest-first, or notifications arrive a few minutes late.
4. S4. No functional effect, just visible wrongness. Text sits a pixel off, or a label has a typo.

The genuinely hard part of grading is scope, so teams look at numbers instead of guessing. A defect that only happens in one browser is an S3 or an S2 depending on whether 2 percent or 40 percent of sessions come from that browser, and the access logs answer that. The workaround question needs the same discipline: a route that exists but that no ordinary user would find is not a workaround.

The grade gets recorded alongside the reproduction steps — the sequence that triggers the defect again. Without those steps, whoever picks it up spends the first hour recreating the situation, and nobody can confirm the scope, which leaves the grade itself unstable.

One more distinction has to stay intact. Severity is how much damage the defect does; priority is the order in which things get fixed. For an incident already affecting the live service, severity effectively is the response order. For a defect in something that hasn't shipped yet, commercial reality reshuffles the order.

The same value gets used four different ways.

1. Deciding response speed. In incident management, the grade is the procedure. An S1 pages the on-call engineer at 3 a.m. and ships as a hotfix that day; an S3 goes onto next cycle's list and waits its turn like any other work.
2. Deciding whether to ship. Quality assurance (QA) uses it as a release gate. Agree in advance that zero S1s and zero S2s means ship, and S3s and below can ride along, and nobody re-litigates "is this good enough to go" the evening before every release.
3. Contractual promises. Enterprise contracts specify a response time per grade — acknowledge a level 1 within an hour and report status within four is a common shape. That makes how you grade something a contractual matter, not just an internal one.
4. Tracking quality over time. Count defects per grade each month. Total count down but S1s up means quality got worse, not better. Counting only the total lets twenty typos hide one payment outage. The same counts also show which parts of the product produce high grades repeatedly, which is a different signal from how many defects each part has.

"This is an S1. Nobody signing up right now can log in."

Scope is everyone and there's no workaround, so move it to the immediate-response path.

"Severity is S3, but I'm raising the priority — that screen is in next week's enterprise demo."

The damage is small, but a commercial reason moves it up the queue.

"We don't know the scope yet, so log it as S2 and bring it down once we do."

Start at the higher grade while the evidence is missing.

Pagedeck makes the grade a required field when a defect is filed. What Theo opens in the morning isn't the whole list but a view filtered to S1 and S2. Last month a defect came in where document lists appeared empty for certain organization accounts, and it was filed as S3 because it looked like one customer. Checking the data showed that organizations with that setting were 18 percent of all paying teams, so it moved to S2 and shipped the same afternoon.

Sofia uses the grade from the other side. When a customer writes in, she can look at the grade the problem was filed under and say when they'll hear back, instead of promising to check and following up twice. For enterprise accounts that sentence is the difference between a routine reply and an escalation.

The most common mistake is treating severity and priority as one value. Fixing the worst thing first seems obvious enough that two fields look redundant. But they answer different questions. Severity is a fact about what is happening; priority is a decision about what to do next. Merge them and the decision overwrites the fact. Grade a demo-screen typo as S1 to get it fixed before Tuesday, and a few months later the monthly counts show that month as having had three critical outages.

Believing that a higher grade gets things fixed faster leads to the same place. It works for a while. Then everyone does it, half the list is S1, and at that moment the grade stops ordering anything. What's left is the situation from before grades existed, except now the field is filled in, so the problem takes longer to notice. That's why the grade belongs to an agreed rubric rather than to whoever filed the report, and why a grade that looks wrong gets argued in terms of which line of the rubric applies.