Instant availability is not enough to manage reliability. A service at 90% for one hour and a service at 99.9% for 30 days have radically different impacts on your error budget. Burn rate is the ratio that measures this speed of consumption and enables alerting proportional to real severity.
The definition
A burn rate of 1 means you are consuming your budget at exactly the expected pace — it will be exhausted by the end of the window. Burn rate 2: twice as fast. Burn rate 14.4: you will exhaust your monthly budget in under 50 hours.
For a 99.9% SLO (expected error rate = 0.1%) and an observed error rate of 5%: burn_rate = 0.05 / 0.001 = 50. You are burning 50 times faster than expected.
Why alert on burn rate instead of raw availability?
Because instant availability does not predict budget impact. A degradation to 99.5% may go unnoticed in real time but silently consume 20% of your monthly budget in 6 hours. A raw availability alert at 99% would fire constantly on normal traffic fluctuations. Burn rate offers a proportional signal: it rises only when the consumption rate exceeds what your SLO can absorb.
The Google SRE multi-burn-rate model
Google SRE recommends four pairs of alert rules on two simultaneous windows: a long window (to detect slow trends) and a short window (to filter false positives on brief spikes). Both conditions must be true at the same time to fire. This avoids alerting on incidents too short to have real impact, while also catching slow degradations before it is too late to act.
| Severity | Long window | Short window | Burn rate | Budget consumed |
|---|---|---|---|---|
| PAGE | 1h | 5min | 14.4x | 2% |
| PAGE | 6h | 30min | 6x | 5% |
| TICKET | 72h | 6h | 1x | 10% |
| TICKET | 30d | 6h | 1x | 100% |
Reading the table
- Page CRITICAL (1h/5min, 14.4×): the budget will be exhausted in under 2 hours. On-call page justified — immediate intervention required.
- Page CRITICAL (6h/30min, 6×): the budget will be exhausted in 5 hours. Still urgent — respond within the hour.
- Ticket (72h/6h, 1×): a slow degradation consuming exactly the expected budget. Handle during business hours. Do not ignore — a burn rate of 1 over 72 hours represents 10% of the monthly budget.
- Ticket (30d/6h, 1×): the service is consuming exactly its budget over the full window. Worth watching — if nothing is fixed, the budget will be exhausted by month end.
Three common mistakes
- Alerting on a single time window — too many false positives on short spikes. The dual-window approach (long + short) is essential for precision.
- Using burn rate thresholds that are too low (< 2) — constant noise on normal traffic variation. Google SRE thresholds (14.4 and 6 for pages) are calibrated to limit false alerts to fewer than one per day.
- Ignoring ticket alerts because they seem less urgent — they often signal slow systemic problems that do not produce outright outages but silently erode reliability over time.
Related articles
Try the simulator →
Alert Noise Reducer →