Burn Rates & SLO Alerting

## The quantity and the speed An SLO sets a target for a service level indicator — say, 99.9% of valid requests succeed over a rolling 30-day window. The complement of the target is the error budget: `1 - 0.999 = 0.001`, or 0.1% of requests. Because 30 days is 43,200 minutes, the same budget is often quoted as time: 0.1% of 43,200 minutes is 43.2 minutes. That quantity alone cannot drive an alert. Knowing you have 43.2 minutes of budget says nothing about whether the current error rate is a rounding error or an emergency. Burn rate supplies the missing dimension: it is consumption expressed as a **multiple of the exactly sustainable pace**. ## Rate 1 is the anchor Burn rate 1 is defined so that the budget is spent precisely at the end of the SLO window — you finish the 30 days having used exactly 100% of the budget. Everything else scales from that anchor: - rate 2 → budget gone in 15 days - rate 10 → gone in 3 days - rate 0.5 → half the budget still unspent at window end - rate 0 → a perfect window This is why burn rate, not raw error ratio, is the natural alerting unit: the number already answers "how long do I have?" ## The arithmetic For a ratio-based SLI the formula is one division: ``` burn_rate = observed_bad_ratio / (1 - slo_target) ``` With a 99.9% target, `1 - target` is 0.001, so: - 0.1% errors → burn rate 1 - 1% errors → burn rate 10 - 100% errors (total outage) → burn rate 1000 Two corollaries fall out. Time to exhaust a full budget is `window / burn_rate`. And the fraction of budget consumed by burning at rate B for an interval T is: ``` budget_fraction = B * T / window ``` A 30-day window is 720 hours, so burning at 14.4x for one hour spends `14.4 * 1 / 720 = 2%` of the budget, and burning at 6x for six hours spends `6 * 6 / 720 = 5%`. Those two products are exactly where the canonical alert thresholds come from. ## Burn rate is always an average over a window A burn rate is not an instantaneous property; it is computed over some observation window. "Burn rate 14.4 over the last hour" means the average bad-event ratio across that hour was 14.4 times the budget rate. This matters twice. First, a short, violent spike inside a long window is diluted: ten minutes of total failure inside a one-hour window averages to roughly 16.7% errors, not 100%. Second, the same real-world event produces different burn-rate readings depending on which window you measure over — so a burn-rate threshold is meaningless unless the window is stated alongside it. ## Why it is the right unit for paging Burn rate is dimensionless with respect to the target. A 99.9% service and a 99.99% service can share the same burn-rate thresholds, because each is measured against its own budget; a raw error-percentage threshold cannot be shared that way, since 0.5% errors is comfortable for one and catastrophic for the other. And burn rate maps directly onto the only question that matters at 3 a.m.: at this pace, how much runway is left? ## Traps The most common mistake is quoting burn rate as if it were an error percentage — "we're burning at 2%" is meaningless. The second is assuming the budget starts full: on a rolling window the budget already reflects the trailing 30 days, so a burn rate of 10 may exhaust an already-half-spent budget in a day and a half, not three days. The third is forgetting that the denominator is bad *valid* events, so misclassifying load-test traffic or health checks as user requests silently moves the number. ## A worked example A 99.9%/30-day service normally serves 0.02% errors (burn rate 0.2 — healthy). A bad deploy pushes it to 3% for 40 minutes. Burn rate during the incident is `0.03 / 0.001 = 30`. Budget consumed is `30 * (40/60) / 720 = 2.8%`. That is a real page-worthy event, and yet it costs under 3% of the month's budget — which is precisely the calibration a fast-burn alert is trying to achieve.