SLO Burn-Rate Calculator
Pick an SLO (99% to 99.99%), a window, and your current error rate: get the error budget in minutes and failed requests, the burn-rate multiple, time-to-exhaustion at the current pace, and the Google-SRE multiwindow alert table with the rows that would fire highlighted.
| Burn rate | Over | Error rate at your SLO | Action |
|---|---|---|---|
| 14.4× | 1 h | 1.44% | page |
| 6× | 6 h | 0.60% | page |
| 1× | 3 d | 0.10% | ticket |
Error budgets: reliability as a currency
An SLO quietly defines a spending account: 99.9% over 30 days means 0.1% of requests — about 43 minutes of full downtime — are allowed to fail. That allowance is the error budget, and it reframes reliability from "never fail" (impossible, and paralyzing) to "fail within budget" (measurable, and spendable on launches, migrations and risky deploys).
Burn rate: the speedometer
The budget alone says nothing about urgency — the burn rate does. It is your current error rate divided by the sustainable one: burn 1× spends the budget exactly by window's end; burn 14.4× torches 2% of a month's budget every hour. Same outage, different SLOs, wildly different urgency — which is exactly why mature teams alert on burn, not on raw error percentages.
Why multiwindow alerts won
Fixed-threshold alerts fail in both directions: tight ones page at 3am for blips that self-heal, loose ones sleep through slow leaks that eat the month. The Google SRE answer — the table in this tool — checks burn over multiple windows: 14.4× over 1 hour pages (fast, severe), 6× over 6 hours pages (sustained), 1× over 3 days tickets (a leak, not a fire). Each threshold spends a fixed fraction of budget before firing, so the same rules work at any SLO.
What to do when the budget empties
The budget's real power is the policy attached to it: budget gone → feature launches freeze, risky deploys wait, engineering shifts to reliability until the window recovers. That converts an abstract nine into an organizational decision rule — and ends the eternal product-vs-reliability argument with arithmetic instead of meetings.
How it works
- Error budget = (1 − SLO) × window; shown as minutes and failed requests.
- Burn rate = current error rate ÷ (1 − SLO).
- Exhaustion = window ÷ burn rate.
- Alert table = Google SRE multiwindow reference; firing rows highlight.
Frequently asked questions
What is a burn rate?
The ratio between how fast you are consuming error budget and how fast you are allowed to. Burn 1× means your error rate exactly equals your budget (1 − SLO) — you finish the window with zero left. Burn 10× means the whole month’s budget disappears in three days.
How big is an error budget really?
Small: 99.9% over 30 days allows ~43 minutes of full downtime — or the equivalent spread as partial errors. 99.99% allows 4.3 minutes. The calculator also converts it to failed-request counts at your traffic, which is usually the more intuitive number.
Why alert on burn rate instead of raw error rate?
A fixed error-rate threshold is either too twitchy (pages on blips) or too slow (misses slow leaks). Burn-rate alerting scales with your SLO automatically: page when burning 14.4× over an hour (2% of the month’s budget gone in 60 minutes), ticket at 1× over days. Same rule works at any SLO.
Where do the 14.4× and 6× thresholds come from?
The Google SRE workbook: 14.4× over 1 hour spends 2% of a 30-day budget (urgent, page), 6× over 6 hours spends 5% (page), 1× over 3 days spends 10% (ticket). They balance detection speed against false pages, and pair each fast window with a short confirmation window in production setups.