A service level objective sets the reliability you promise, and an error budget says how much room is left over the period. Neither answers the one question that matters the moment things start going sideways: page someone now, or let it wait until morning? An alert that only watches the remaining budget is structurally late, because it only fires once the damage is done. That gap is what multi-window burn-rate alerting closes, a method Google formalized in its SRE workbook and that simplifies well for a team without a dedicated SRE.

Burn rate is a speed, not a level

Burn rate measures how fast you’re spending the error budget, not how much is left. A burn rate of 1 means you’re spending the budget exactly at the pace the SLO assumes; a burn rate of 10 means that, at the current pace, the whole period’s budget would go ten times faster than planned. The formula is one line: burn rate = (fraction of budget consumed) divided by (fraction of the period elapsed). On a 30-day SLO, burning 5% of the budget in a single hour gives a burn rate of 0.05 / (1h / 720h) = 36, a pace that would empty the month’s budget in under a day if it held.

The problem with a single window

The naive approach alerts whenever the burn rate computed over one window crosses a threshold, and the choice of window forces an uncomfortable trade-off. A short window (5 minutes) catches a real outage fast, but also reacts to an isolated spike that has already resolved by the time the pager fires, the same failure mode as an alert with no for clause described in symptom-based Prometheus alerts. A long window (several hours) smooths that noise out, but catches a real degradation too late: by the time the rolling average moves, a good chunk of the budget is already gone.

Two windows, one decision

The fix isn’t picking between the two windows, it’s requiring them to agree. A multi-window rule computes the burn rate over a long window (say, one hour) to judge whether the situation is serious, and over a short window (say, five minutes) to confirm it’s still happening right now. The alert only fires when both cross the same threshold at the same time. A brief spike pushes the short window up but not the long one, so nothing fires. A degradation that settles in eventually pushes both, and fires quickly once it does, because the short window reacts fast as soon as the long window has confirmed the scale of the problem.

Two tiers for two urgencies

A single pair of windows doesn’t cover every case, because a slow budget drain doesn’t need to wake anyone up. Two tiers are enough for a small team. A fast tier, on a short long-window (one hour, confirmed at five minutes) with a high burn-rate threshold, pages: the trajectory would empty the budget in a day or two if nothing changes. A slow tier, on a wider long-window (three days, confirmed at a few hours) with a moderate burn-rate threshold, only opens a ticket for business hours: the trajectory would empty the budget in a week or more. The formula above gives the exact threshold for each tier once you’ve picked the window and the exhaustion time you’re aiming for.

What you need instrumented already

These rules compute nothing beyond what the RED method already exposes: an error rate, aggregated over two windows instead of one. The Prometheus starting point looks like this, with N the tier’s burn rate and objective the error fraction the SLO tolerates (0.001 for 99.9%):

(
  sum(rate(http_requests_total{status=~"5.."}[1h]))
  /
  sum(rate(http_requests_total[1h]))
) > (N * objective)
and
(
  sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
) > (N * objective)

The and operator does all the work: drop it and you’re back to a single-window alert. Each tier (page or ticket) is a separate rule with its own window pair and its own N, routed differently in Alertmanager through the severity label, the same way symptom-based alerts are.

Where this fits

Burn-rate alerting doesn’t replace the symptom-versus-cause discipline, it sharpens one axis of it: the speed at which an already-defined budget gets spent, instead of a fixed threshold. An alerting setup built this way is a core deliverable of a reliability and observability engagement; more in the observability category.