SLOs, error budgets and burn rate
How do error budgets and burn-rate windows make the alerting trade quantitative?
Error budgets put the first real number on the trade between coverage and attention.
An error budget is the amount of failure your objective allows. Worked example: a 99.9% objective over a month (30 days = 43,200 minutes) allows 0.1% failure = 43.2 minutes of badness.
Burn rate is how fast you use the budget compared with the sustainable pace. Burn rate 1 would use exactly the whole budget in exactly 30 days. Burn-rate alerting fires when you are consuming budget at k times the sustainable rate. The choice of k and the time window is an explicit purchase of detection speed with false alarms:
| Rule | Budget spent before it fires | Character |
|---|---|---|
| 14.4× over 1 hour | 14.4 × 1 h / 720 h = 2% | fast, noisier |
| 6× over 6 hours | 6 × 6 h / 720 h = 5% | slower, quieter |
(A 30-day month has 720 hours. At 14.4× burn, the whole month's budget is gone in 720 / 14.4 = 50 hours.)
Two more details:
- A short confirmation window layered on the long one (for example, also require that the last 5 minutes are still bad) suppresses the recovery tail: it stops the alert from continuing to fire after the problem has already ended.
- This is the one mechanism here that makes the trade quantitative instead of aesthetic. You can say "we accept spending 2% of the budget before the page fires".
# Pseudo-config: page if the error budget burns 14.4x too fast,
# measured over 1 hour AND still true in the last 5 minutes.
alert: RevenueTableStale
expr: burn_rate_1h > 14.4 and burn_rate_5m > 14.4
severity: page