Error Budget Burn Rate
Burn rate measures how fast an SLO error budget is being consumed relative to plan, with multi-window alerts firing when spending outruns the budget period — fast burns page, slow burns ticket.
Definition
An error budget converts an availability target into allowed bad events per period. Burn rate is the ratio of the current error rate to the maximum sustainable error rate. Multiwindow burn alerts compare short and long windows — a high short-window rate over a confirming long window pages immediately; moderate sustained burn over the long window creates a ticket. The alert thresholds derive from how fast the budget would be exhausted.
Context and scope
The SRE workbook pattern for SLO alerting: replaces static threshold alerts with budget economics. Implemented in Prometheus recording rules and SLO platforms.
Common misconceptions
- Burn rate is just a fancy error rate — it is the error rate normalized by budget: the same 0.1 percent is an emergency at 99.99 percent and noise at 99 percent
- A single alert window suffices — single windows trade false positives for late detection; paired windows verify sustained burn
- Burn alerts replace symptom alerts — they prioritize by customer impact; component-level symptom alerts still belong on-call for diagnosis
Anti-patterns
- Paging on every error rate wiggle and training on-call to ignore budget alarms
- Computing burn against the wrong window granularity so the alert fires after the budget is gone
- Defining SLIs that do not reflect user experience, making budget burns invisible to customers and vice versa
Related concepts
Related examples
Authoritative source
What it is
An SLO of 99.9 percent over 30 days grants roughly 43 minutes of allowed downtime. The question alerting must answer is not “is the error rate high” but “are we spending the budget too fast to last the period”. Burn rate answers that.
How it works
Compute the ratio of observed bad-event rate to the budget rate. A 14.4x burn rate exhausts a 30-day budget in two days — page. A 1x burn rate spends exactly on plan — fine. Multiwindow alerts pair a short window for sensitivity with a long window for confirmation: both above threshold means sustained fast burn; only the short one is a blip.
When to adopt
After defining honest SLIs and SLOs with real error budgets. Before that, burn alerts measure spending of a budget nobody agreed to. Pair with a policy: exhausting budget halts feature work in favor of reliability, or the number is decoration.
Pitfalls
Window arithmetic must match the budget period — thresholds are derived, not invented. SLI choice dominates: measuring server uptime while users see failures burns an invisible budget. Seasonal traffic shifts the denominator; normalize per-request, not per-minute, or low-traffic nights fake burn.