SLO & Window
Consumption
Burn rate needs the elapsed fraction: it compares consumption so far against the pace that would exactly exhaust the budget at window close.
A 99.9% SLO is 43.2 minutes per month — spend it on deploys, lose it to incidents. Feed in your SLO, window, and consumed downtime, and get the number that tells you whether to ship or freeze.
Burn rate needs the elapsed fraction: it compares consumption so far against the pace that would exactly exhaust the budget at window close.
| Burn Rate | Budget Consumed | Window | Action |
|---|---|---|---|
| 14.4× | 2% | 1 hour | Page immediately — active incident |
| 6× | 5% | 6 hours | Page during working hours — sustained degradation |
| 1× | 10% | 3 days | File a ticket — slow bleed |
| SLO | Per Month | Per Year | Operating Model |
|---|---|---|---|
| 99% | 432 min (7h 12m) | 3d 15h 36m | Internal tools, batch |
| 99.9% | 43.2 min | 8h 45m | SaaS APIs, business apps |
| 99.95% | 21.6 min | 4h 22m | Consumer platforms |
| 99.99% | 4.3 min | 52m 34s | Payments, critical infra |
| 99.999% | 26 sec | 5m 15s | Carrier-grade, life-critical |
Error budget = (1 − SLO) × window. That one line replaces every argument about "how stable is stable enough" with a number both engineering and product can read. A 99.9% availability SLO over a 30-day window permits 43.2 minutes of downtime; every minute of outage draws from that account. The budget is not a tolerance for carelessness — it is a resource to be spent on deploys, migrations, and experiments, which is exactly why Google's SRE framework calls it a budget rather than a target.
Budget remaining is a postmortem tool; burn rate is the alarm. Burn rate compares how fast you are consuming the budget against the pace that would exactly exhaust it at window close — a rate of 1 means you arrive at zero with nothing to spare. The 14.4×/1h threshold pages on-call because it spends 2% of a monthly budget in a single hour; the slow 1×/3d burn catches the regression that never trips a spike alert but quietly eats the month. Alerting on burn rate instead of raw error rate matters: a 1% error rate is fine against a 99% SLO but is a 10× burn against 99.9% — same signal, wildly different meaning.
The value of an error budget is not the freeze — it is that the policy was written while everyone was calm. Graduated responses work best: review what spent the budget at 50%, require sign-off for risky changes at 75%, freeze non-essential deploys at 100%. And keep the SLO stricter than the SLA: if the public contract promises 99.9%, an internal SLO of 99.95% leaves a safety margin where internal failures do not yet breach the customer promise. Budget your nines before the incident, not after.