Setting bug SLAs by severity

A customer reports that checkout fails for anyone paying with a saved card. The ticket is filed at 14:20 on a Thursday. It is picked up on Monday morning, because nobody was sure whose job it was over the weekend.

Nothing went wrong with anyone's intentions. What was missing was a rule saying "a bug like this gets a human within one hour, and a fix within a day, and here is who." That rule is a bug SLA.

Short version

An SLA (service level agreement) here is a promise about time: how fast you respond, and how fast you fix.
Track two clocks per bug, not one — time to first response and time to resolution.
Four severity levels is enough. Five is the maximum before people stop distinguishing them.
A target nobody can hit is worse than no target, because people stop believing all of them.
Every breach needs a defined action, otherwise the SLA is decoration.
Review hit rates quarterly and change the numbers, not the definitions.

Severity and priority are different things

Get this straight before you set any numbers, because mixing them is the most common reason SLAs fail.

Severity is how bad the bug is when it happens. It is a property of the bug. A tester can set it.
Priority is how soon you will work on it. It is a business decision. A product owner or triage group sets it.

They usually agree, but not always. A total crash in a feature used by four internal users is high severity and low priority. A minor visual glitch on your pricing page is low severity and high priority, because it costs sales.

SLAs should be driven by severity plus reach, with priority allowed to override. That way testers can set the clock honestly without needing business context, and triage can adjust when the business context matters.

Define severity so two people agree

Definitions must be testable, not adjectival. "Critical means very serious" produces arguments. Write them as conditions.

Level	Definition	Examples
S1 Critical	Core function unusable, no workaround, or data loss, or a security exposure. Affects many users.	Checkout returns `500` for all saved cards; login fails for all users; customer data visible to the wrong account
S2 Major	Important function broken or badly wrong, but a workaround exists, or it affects a limited group.	Invoice PDF shows the wrong tax total; export fails on Firefox only; dashboard blank for accounts with over 500 records
S3 Minor	Function works, but wrongly or awkwardly. Users can complete the task.	Sort order resets after paging; validation message appears under the wrong field
S4 Trivial	Cosmetic or text. No effect on the task.	Button 4px misaligned on the settings page; "recieve" misspelled in a tooltip

Two rules that end most disputes:

If there is no workaround, it is at least S2. Workaround availability is the single strongest signal.
Anything involving money, personal data, or permissions gets bumped one level up. A minor billing bug is not minor.

A starter SLA table

Use this as a first draft and adjust after one quarter of real data. These numbers assume a normal product team with business-hours support and an on-call rota for S1.

Severity	First response	Fix or mitigate	Clock runs	Escalates to
S1 Critical	1 hour, 24/7	24 hours, or a mitigation the same day	Around the clock	On-call engineer, then engineering manager at 4 hours
S2 Major	1 business day	5 business days	Business hours	Team lead at 3 days
S3 Minor	3 business days	Next release, or 30 days	Business hours	Backlog review
S4 Trivial	5 business days	No fix target — batched or closed	Business hours	None

Two details that matter more than the numbers themselves.

"Mitigate" counts as meeting the S1 fix target. Turning off the broken feature with a flag, rolling back the deploy, or routing affected users to a fallback all stop the harm. A proper fix can follow under an S2 clock. Without this, teams rush a risky permanent fix under pressure at 23:00, which is how one incident becomes two.

The clock pauses when the ball is in someone else's court. If you ask the reporter for their browser version and account email, the clock stops until they answer. Otherwise your SLA measures their response time, not yours. Make the pause explicit — a waiting-on-reporter status that is visible in reports.

First response is not "someone looked at it"

The first response clock is the one teams get wrong most often. It is not a status change, and it is not an automatic acknowledgement email.

A first response means a person has:

Reproduced it, or tried to and said what happened
Confirmed or corrected the severity
Named an owner, or said explicitly why there is not one yet
Written that in the ticket, so the reporter can see it

Not a response: Ticket moved from New to Triage.

A response: "Reproduced on staging with [email protected] — the POST /api/v1/checkout call returns 500 when a saved card is used. Console shows TypeError: Cannot read properties of undefined (reading 'last4'). Confirming as S1, Marek is on it, update by 16:00." — 14:52

The second one takes four minutes and removes the entire question of whether anything is happening.

What happens when an SLA is breached

An SLA without a breach process is a wish. Breach handling should be automatic and boring — no blame, just a defined next step.

The ticket is flagged automatically. Your tracker can do this with a due date on the status. Do not rely on a person noticing.
It escalates one level. S1 goes to the engineering manager; S2 goes to the team lead. Escalation means someone senior now owns the decision, not that someone gets shouted at.
A written reason is added to the ticket. One line. "Breached — the reproduction needs production data access and that took two days to arrange."
The severity is re-checked. Repeated S2 breaches often mean the bug was actually S3 and nobody wanted to say so.
Breaches are counted, not punished. They are reviewed in aggregate at the end of the quarter.

The last point is the one that decides whether your SLA survives. If a breach means an uncomfortable meeting for an individual, people will avoid breaches by mislabelling severity, and your data becomes fiction within two months.

Keeping SLAs honest

Five habits separate a working SLA from a wall poster.

1. Set targets you already hit about 70 to 80% of the time. Look at your last quarter before choosing numbers. If your real median S2 fix time is 9 days, do not set a 2-day target. Set 7, hit it, then tighten. Targets that are missed constantly train everyone to ignore all of them.

2. Reserve capacity for bug work. An SLA is a capacity promise in disguise. If every sprint is 100% feature work, every bug is an interruption and the SLA loses to the roadmap every time. Reserving 15 to 20% of sprint capacity is what makes the numbers achievable.

3. Watch for severity drift. The cheapest way to hit an SLA is to file everything as S3. Track the distribution of severities each month. If S1 and S2 quietly shrink while customer complaints stay flat, the definitions are being bent. Sampling ten closed tickets a month and re-rating them yourself catches this early.

4. Make the response clock easy to beat. Most first-response breaches are not laziness — they are a ticket that cannot be acted on, because it lacks the URL, the browser, the account, or the error. When reports arrive complete, the four-minute triage response is actually possible. Tools such as Crosscheck attach the screenshot, console output, network requests, and environment details at the moment the bug is reported, which removes the most common reason a first response takes three days.

5. Report hit rate, not average time. Averages hide the failures. One bug fixed in 40 days and nine fixed in a day gives a healthy-looking average of five days. Report "S2 fix target met: 82% of 45 bugs" instead.

A simple quarterly review

Fifteen minutes, four numbers per severity level:

How many bugs at this severity
Percentage meeting the response target
Percentage meeting the fix target
The three worst misses, with their one-line reasons

Then make exactly one change. Either loosen a target you never hit, tighten one you always beat by a wide margin, or fix the process problem the three worst misses have in common. Changing five things at once means you learn nothing about which change worked.

Frequently asked questions

Should the SLA clock start when the bug is reported or when it is triaged? When it is reported. Starting at triage lets a bug sit in a queue for a week without technically breaching anything, which defeats the purpose.

Do SLAs apply to internally found bugs as well as customer-reported ones? Yes for severity-based fix targets, but response targets can be looser for internal reports. A tester who found it is already the response.

What if the same bug affects one enterprise customer badly and nobody else? That is exactly where priority overrides severity. Keep the severity honest at S2 or S3, raise the priority, and note the reason. Do not inflate severity for commercial reasons — it corrupts your data.

How many severity levels should we have? Four. Five is workable if S1 is reserved for outages. Beyond that, people cannot tell adjacent levels apart, and the extra levels get used inconsistently.

Is it worth having SLAs on a small team of five? Yes, but keep them to two lines: a response target and an S1 fix target. Small teams need the escalation rule far more than the reporting.