Burn Rate
Also known as: error budget burn rate
Burn rate is how fast an error budget is being consumed relative to the rate that would exactly exhaust it over the SLO window. A burn rate of 1 means the budget runs out precisely at the end of the window; a burn rate of 14.4 exhausts a 30-day budget in about 50 hours.
Last reviewed · Part of the Architecture Glossary
In practice
Burn-rate alerting is what replaced "alert when error rate > 1%". A fixed threshold either pages on noise or misses a slow bleed; a burn rate is scaled to the budget, so the alert means the same thing on every service.
The multi-window pairs from the SRE workbook, for a 30-day window:
| Burn rate | Long window | Short window | Budget consumed | Action |
|---|---|---|---|---|
| 14.4 | 1 hour | 5 min | 2% | Page |
| 6 | 6 hours | 30 min | 5% | Page |
| 3 | 1 day | 2 hours | 10% | Ticket |
| 1 | 3 days | 6 hours | 10% | Ticket |
The short window is the part people drop, and it is what prevents the alert from firing for an hour after the incident is already resolved.
When it matters
Designing the alert set for any service with an SLO — this is the alert that should page, in place of the CPU and disk thresholds it retires.
Common mistake
Paging on a 1x burn rate. That fires whenever the service is merely performing at exactly its target, which is the expected state, and it teaches the on-call to ignore the alert. Page at 14.4x and 6x; ticket the rest — the calculator shows time-to-exhaustion for each.
See also
- Error BudgetAn error budget is the amount of unreliability an SLO permits — the complement of the target.
- SLO (Service Level Objective)An SLO is a target value for an SLI over a window — for example, 99.9% of requests succeed over 28 days.
- SLI (Service Level Indicator)An SLI is a quantitative measure of one aspect of service behaviour, expressed as the ratio of good events to valid events — successful requests over total requests, say.