tools / slo-error-budget
SLO Error Budget Calculator
Allowed downtime per window and burn rate for an availability target.
Error budget
Remaining
Burn rate
Key facts
| Error budget | (1 − SLO) × window |
|---|---|
| Burn rate | actual spend rate ÷ allowed spend rate |
| 30-day budgets | 99% ≈ 7.2 h · 99.9% ≈ 43 min · 99.99% ≈ 4.3 min |
| Each extra nine | Cuts the budget 10× |
| Burn rate 1× | Uses exactly the whole budget by the end of the window |
Worked example
A 99.9% SLO over 30 days. Ten days in, you've had 20 bad minutes.
budget = 0.001 × 30 × 1,440 = 43.2 min allowed = 43.2 / 30 = 1.44 min/day actual = 20 / 10 = 2.0 min/day burn rate = 2.0 / 1.44 ≈ 1.4× runs out = 43.2 / 2.0 ≈ day 21.6
At this pace the budget is gone three weeks in. Slow risky changes now, or accept missing the SLO.
Minutes or requests
Time-based budgets count bad minutes. Request-based budgets count failed requests: at 99.9% and 10 million requests a month, 10,000 may fail. Request-based is fairer for services with uneven traffic, since a bad minute at 3 a.m. affects fewer users.
FAQs
Why not aim for 100%?
Every nine costs far more effort than the last, and users can't tell the difference past what their own network and devices allow. The budget is permission to ship changes.
When should a burn rate alert fire?
A common pattern pairs a fast window that catches high burn (for example 14× over an hour) with a slow window that catches steady leaks (for example 1× over days).
Rolling or calendar window?
Rolling windows reflect what users felt recently and avoid a reset that hides problems. Calendar windows are easier to report on.