SLOs & error budgets

The sponsor says "make it 100% accurate." The system, measured, fails about 2% of the time on a good day and spikes on bad ones. The professional move is not to promise harder — it's to turn quality into a target with a budget: an SLO you can monitor, an error budget you spend, and a defined consequence when it runs out. This page lets you feel what choosing that number actually commits you to.

SLOerror budget burn-downincident days

Same month, same failures — the SLO decides whether you're in crisis

One simulated month: ~2,000 requests a day, a 2% baseline failure rate, and three incident days at 8% (a bad deploy, a flaky upstream). None of that changes when you move the slider — only the promise changes. Watch what the same reality does to different promises:

The burn-down

quality SLO target the promise: at least this share of requests succeed this month

The mechanics are almost embarrassingly simple, which is why they work in a meeting. An SLO of 98% on ~60,000 requests is a budget of ~1,200 allowed failures for the month. Every failure spends from it; incident days spend fast. When the line crosses the budget, the SLO is breached — and the pre-agreed consequence kicks in: feature launches freeze, the team works reliability until the budget recovers. That consequence clause is the whole point: it converts an argument you'd otherwise have during an incident into a decision everyone already signed.

Notice what the slider teaches about negotiation. This system genuinely achieves about 97.4% — so a 97% SLO is a promise it can keep with room to breathe, 98% is a promise the incident days will break some months, and 99.5% is a promise that was broken by day 8 — before two of the three incidents even happened. Signing an SLO the system can't meet doesn't make the system better; it makes the dashboard red and the promise worthless. The honest sequence is: measure what the system does → set the SLO just below it → improve the system → then raise the promise.

# the package a pro presents instead of "it'll be very accurate":
quality SLO   : 97.0% of requests pass the eval-aligned check, monthly window
error budget  : 3.0% x volume  (~1,800 requests/month)
burn alert    : page at 50% consumed before day 15
consequence   : budget exhausted -> launches freeze, reliability work until recovered
escalation    : failures route to human queue; SLA there: first response < 4h

⚠️ Traps & honesty: the month here is simulated (volumes, the 2% baseline, three 8% incident days are assumptions) — the mechanics of budget arithmetic are the transferable part · a quality SLO needs a measurable definition of failure (an eval-aligned check, sampled human review) — an SLO over an unmeasured property is decoration · the achieved rate ~97.4% is only visible because everything is logged; you cannot set an honest SLO for a system you don't measure · error budgets came from SRE practice for availability; applying them to model quality is standard now but the failure check is noisier than a ping — build slack into the target for that noise.

Takeaways: "100% accurate" is not on the menu; a quality SLO + error budget + consequence clause is — and it converts incident-day arguments into pre-signed decisions · budget = (1 − SLO) × volume; incident days are budget fires, which is why the alert fires on burn rate, not just the total · set the SLO from the measured rate, slightly below it — a promise above your measured reality is a scheduled breach · raising the SLO is an engineering project, not a negotiation outcome. Next: the model-upgrade pipeline.

Second opinion (taught here — these corroborate): Google SRE · error budgets · Anthropic docs · defining success criteria.