How is an SLO burn rate actually calculated, and why does the same raw error percentage warrant a page in one time window but only a ticket in another?

Burn rate is like judging whether a car is going to run out of gas before reaching its destination — knowing the fuel gauge reads 'half full' tells you almost nothing on its own; what actually matters is the rate of consumption relative to the remaining distance. A car burning fuel at a rate that would empty the tank in 500 miles is perfectly fine for a 200-mile trip and alarming for a 1,000-mile one. An SLO's error budget is the fuel tank, the 30-day (or whatever) SLO window is the trip distance, and burn rate is precisely that consumption-rate-relative-to-remaining-distance calculation, expressed as a multiple of the 'sustainable' rate that would use exactly 100% of the budget by the end of the window and no more.

This multiple-of-sustainable-rate framing was designed specifically to solve the problem of a single fixed error-rate threshold being either too noisy or too slow depending on how long the bad behavior persists. A fixed alert like 'page if error rate exceeds 1%' either fires on every brief, self-resolving blip (paging for something that would have consumed a negligible fraction of the actual monthly budget) or, if you raise the threshold to avoid that noise, fails to catch a sustained, lower-level degradation that quietly exhausts the entire monthly budget over several days without ever crossing the naive fixed threshold. Burn rate solves this by making the alert's severity a function of both how bad the error rate is and how long it's projected to last, expressed relative to the budget itself rather than an arbitrary absolute number.

Step by step, the calculation multiplies together two dimensions on purpose: burn rate equals the observed error rate divided by the budget's allowed error rate (1 minus the SLO target), evaluated over a specific lookback window. A 99.9% SLO allows a 0.1% error rate as its sustainable baseline; observing a 1.44% error rate over a short window is a burn rate of 14.4x — at that pace, the entire 30-day budget would be gone in about 30/14.4 ≈ 2 days, which is genuinely urgent and worth an immediate page. The same 1.44% error rate observed as an average over a much longer 6-hour window, if it's actually a brief spike that's already resolved, produces a much smaller *sustained* burn-rate reading because the long window dilutes a short spike down toward the noise floor — this is precisely why Google's SRE workbook recommends alerting on *multiple* window-and-threshold pairs simultaneously (commonly a fast 1-hour/5-minute pair for immediate paging and a slower 6-hour/30-minute pair for ticket-level investigation) rather than picking just one window size, since a single window size is always a trade-off between catching short severe spikes and catching long slow leaks.

At production scale, teams typically implement a two-tier (sometimes four-tier) burn-rate alerting scheme: a high-multiplier, short-window alert (e.g., 14.4x sustained for 2 minutes) pages immediately because it implies the budget could be fully gone within hours if unaddressed, while a lower-multiplier, longer-window alert (e.g., 3x sustained for an hour) creates a ticket for investigation during business hours because at that pace, the budget still has days of runway left even if the trend continues unaddressed. The engineering value of this design is that it makes the page-versus-ticket decision an automatic, calculated output rather than something an on-call engineer has to mentally estimate under pressure during an actual incident.

The gotcha: teams that implement burn-rate alerting with only a single window size inevitably end up either paging on harmless short blips (window too short) or missing a real, slow-building budget-exhausting trend until it's too late to fix gracefully (window too long) — the fix genuinely requires at least two window-and-multiplier pairs evaluated in parallel, and skipping this dual-window design is one of the most common mistakes teams make when they implement error budgets for the first time, often discovering the gap only after either alert fatigue or a missed slow-burn incident forces them to revisit the design.