What's the difference between a response SLA and a resolution SLA?

The response SLA is the time to acknowledge and triage a bug — confirm it's real, set a severity, and assign an owner. The resolution SLA is the time to ship a fix or an accepted workaround. Response should be short and consistent across all severities; resolution should scale with severity.

Should SLAs be based on severity or priority?

The resolution clock should be driven by severity (how badly the product is broken) combined with priority (how soon it must be fixed given business context). Severity sets the default tier; priority lets you fast-track or defer a specific bug. Never let a single loud stakeholder override the tier without a documented reason.

What happens when we miss an SLA?

A missed SLA should trigger an escalation, not a penalty. Route the bug to a lead, re-check severity, and record why it slipped. Track breach rate per tier over time: a consistently breached tier means the target is unrealistic or the tier is over-subscribed, and the fix is to re-baseline the target, not to blame the team.

How to Set Bug SLAs by Severity: A Practical Guide

Q: When does the SLA clock start?

Start it when a reproducible report exists — one with steps, environment, and evidence — not when a vague complaint lands. If half your intake is unreproducible, your resolution SLA measures your triage backlog, not your fix speed. Capturing complete evidence at report time is the single biggest lever on hitting resolution targets.

A bug SLA (service-level agreement) sets two targets for each severity level: a response target — how long until someone acknowledges and triages the bug — and a resolution target — how long until it's fixed or has an accepted workaround. A workable SLA keeps the response window short and identical across severities so triage never stalls, then scales the resolution window by severity so the bugs that break the product most get fixed first. The clock only means something if it starts from a reproducible report, not a vague complaint.

What is a bug SLA?

A bug SLA is a written commitment that pairs each severity level with time targets. It exists to make triage decisions predictable: instead of arguing about every incoming bug, the team agrees once on what "critical" means, how fast a critical bug gets a response, and how fast it gets fixed. Everything after that is just applying the rule.

Two clocks matter, and teams routinely conflate them:

Response time — the gap between a bug landing and a human acknowledging it, confirming it's real, assigning a severity, and giving it an owner. This is a triage commitment.
Resolution time — the gap between that acknowledgement and a shipped fix or an accepted workaround. This is an engineering commitment.

Keeping them separate lets you promise something you can actually deliver on the response side (a quick, reliable acknowledgement) without pretending every bug can be fixed on the same timeline.

How many severity tiers should a bug SLA have?

Four tiers is the practical sweet spot: enough resolution to tell a data-loss bug apart from a cosmetic one, few enough that people can classify without a decision tree. A common structure:

Critical (S1) — the product is down, data is being lost or corrupted, or a core flow is completely blocked for many users. There is no workaround.
High (S2) — a major feature is broken or a common flow fails, but a workaround exists or only a subset of users is affected.
Medium (S3) — a feature misbehaves in a noticeable but non-blocking way; users can complete the task with friction.
Low (S4) — cosmetic issues, minor copy errors, or edge cases that don't affect the main task.

Severity measures how badly the product is broken; it is not the same as priority, which is how soon you choose to fix it given business context. A rare crash can be high severity but low priority; a cosmetic bug on your pricing page can be low severity but high priority. If your team blurs these two, that's the first thing to fix — see severity vs. priority for how to classify each independently.

How do you set realistic SLA targets?

Don't copy someone else's numbers. Set targets from your own data and your on-call reality, then tighten them as you improve. Two principles keep targets honest:

Response targets should be short and the same for every tier. Whether a bug is critical or cosmetic, someone should look at it quickly — because you can't know it's cosmetic until you've triaged it. A uniform, achievable response window (measured in hours, not days) means severity is assigned fast and the resolution clock starts on time.
Resolution targets should scale with severity and match your actual capacity. A critical resolution target implies you can interrupt work and ship a fix on that timeline — only commit to what your release process and on-call coverage genuinely support. If you can't hot-fix on a weekend, don't write an SLA that assumes you can.

The right way to pick a resolution number: look at how long your fixes for that tier actually took over the last quarter, take a percentile you can hit most of the time (not your best-ever case), and set the target there. Then make it stricter as the number improves. A target you meet 90% of the time is a real commitment; a target you meet 40% of the time is a wish that erodes trust every time it's missed.

When does the SLA clock start?

This is where most bug SLAs quietly break. If you start the resolution clock the moment a vague message arrives — "the checkout is weird" — then a large share of your SLA time is spent chasing the reporter for steps, environment, and evidence. Your resolution metric ends up measuring your triage backlog, not your engineering speed.

Start the clock when a reproducible report exists: exact steps, the environment (browser, OS, build, account state), and evidence — a screenshot, the console output, and the failing network request. When that arrives with the bug, triage takes minutes and the fix timeline is honest. When it doesn't, you're paying for the reporter's missing context out of your SLA budget.

This is the single biggest lever on hitting resolution targets, and it's an intake problem, not a fix-speed problem. In-app bug reporting tools like Klavity Snap attach the URL, console, network activity, and environment automatically when someone files a bug from inside the product, so reports arrive reproducible by default and the clock starts on real, actionable work instead of a back-and-forth.

How do you enforce an SLA without turning it into a blame machine?

An SLA is a routing tool, not a stick. Build three habits around it:

Escalate on breach, don't punish. When a bug approaches or crosses its resolution target, auto-route it to a lead who re-checks severity and either reassigns, re-scopes, or re-tiers it. The goal is to unstick the bug, not to find someone to blame.
Track breach rate per tier, not per person. If one tier is breached constantly, the target is wrong or that tier is over-subscribed — both are process signals. Re-baseline the number instead of leaning on the team to sprint against an impossible clock.
Review the SLA on a cadence. Revisit targets each quarter against actual resolution times. As your evidence quality and triage improve, tighten the targets; if a target has been unmet for two straight quarters, it's fiction — fix it.

Pair this with a clean triage process so bugs reach the right tier quickly in the first place; see how to triage a bug backlog for a repeatable flow that keeps the SLA meaningful.

Putting it together

A bug SLA that works has four properties: a short, uniform response target so triage never stalls; severity-scaled resolution targets set from your own historical data at a percentile you can actually hit; a clock that starts on a reproducible report so the metric measures fixing, not chasing; and a breach process that escalates and re-baselines instead of assigning blame. Get those four right and the SLA stops being a number you dread and becomes the rule that decides, automatically, which bug gets worked first.