Burn Rate (SLO Error Budget)

An SLO defines an acceptable failure ratio over a rolling window (e.g., 99.9% availability over 30 days), which implies a fixed error budget: the total amount of allowed bad events in that window. Burn rate quantifies how fast that budget is being spent relative to a uniform consumption rate. Formally, burn rate = (1 – SLI) / (1 – SLO), measured over a given lookback window. A burn rate of 1.0 means the service is failing at exactly the rate the budget tolerates for the full window; a burn rate of 30x means the entire 30-day budget would be exhausted in roughly 24 hours if sustained.

The critical engineering insight, formalized in Google’s SRE Workbook, is that a single-window burn rate check is structurally flawed. A short window (e.g., 5 minutes) reacts fast but is highly sensitive to noise and transient blips, producing false pages. A long window (e.g., 24 hours) is statistically stable but detects real incidents far too slowly, potentially after the budget is already gone. The standard solution is multi-window, multi-burn-rate alerting: pair a long window (for statistical confidence, e.g., 1h) with a short window (for fast recovery detection, e.g., 5m) that must both exceed the threshold before paging. This gives fast detection with low false-positive rate, and fast alert-clearing when the short window recovers even if the long window hasn’t rolled off yet.

• Threshold tiers: Typical implementations define multiple severity tiers — e.g., 14.4x burn rate over 1h+5m windows pages immediately (would exhaust a 30-day budget in ~2 days), while 6x over 6h+30m opens a ticket (exhausts budget in ~5 days).
• Denominator sensitivity: Because the formula divides by (1 – SLO), tightening an SLO (e.g., from 99.9% to 99.95%) mechanically doubles burn rate for the same raw error rate, requiring threshold recalibration whenever SLO targets change.
• Low-traffic noise: Services with sparse request volume produce statistically unstable SLIs; a handful of failures can spike burn rate to absurd multiples with no real signal, requiring minimum-sample-size gating before evaluating burn rate at all.
• Composite SLIs: When an SLO aggregates multiple SLIs (latency + availability + correctness), burn rate must be computed per-SLI or on a combined ‘good events / valid events’ ratio, not averaged naively, or masking effects hide real degradation.

Burn rate alerting fundamentally changes the on-call contract: instead of paging on absolute thresholds (“error rate > 1%”), teams page on budget depletion trajectory, which is portable across services with wildly different baseline traffic and failure tolerances. It also feeds directly into error-budget policies — automated feature-freeze or rollback triggers when cumulative burn crosses a governance threshold, making it a control-plane signal as much as an alerting signal.

Correctly implementing burn-rate alerting requires accurate, low-cardinality SLI counters (good/total events), a well-defined budget window, and careful threshold derivation tied to organizational tolerance for time-to-detect versus false-positive rate; treating it as a simple derived metric without the multi-window design collapses back into the same noisy, slow alerting it was meant to replace.