Burn-rate alerts: know you're burning before the budget is gone

An error budget checked at the end of its window is not a budget — it is an autopsy. The 28-day window ends, the number is red, and the only thing anyone learned is that the month is unsavable. Burn-rate alerts fix the timing: instead of watching the total, they watch the pace of spending against the budget, and they say something while there is still budget left to save. This page is the alerting math that makes an error budget policy fire on time; the SLO definition sets the bar, this page builds the smoke alarm on it.

Why not just alert when the error rate crosses the target? Because a 0.4% error rate on a 99.7% target means nothing on its own: for ten minutes it is a rounding error, for two days it is the whole budget. The rate of spending is the quantity that carries urgency, and pace is what burn-rate alerts measure.

1. The one formula

Burn rate = fraction of budget spent ÷ fraction of window elapsed. A burn rate of 1.0 is exactly on pace to end the window with the budget spent to zero — technically a breach, practically a coin flip. Below 1.0 you are trending safe; above it you are spending faster than the month can afford, and the higher it goes, the fewer hours you have left:

• 1.0× — on pace. 121 bad minutes a month, arriving at 11 seconds an hour. No alarm; this is what “healthy” feels like.
• 6× — at this pace the budget is gone in about 4.7 days. Serious, not yet catastrophic. Ticket territory.
• 14.4× — budget gone in under 2 days. Something is actively wrong right now. This is where a pager goes off.
• 60× — budget gone in under 12 hours. This is an incident in progress; honestly, by this point your paging policy probably fired for the raw outage already.

Do the arithmetic once, on one line, for your own budget: B = 121 minutes over 28 days = 40,320 minutes, so allowed pace = 11s/hour. 14.4× = 2.6 minutes of badness per hour (2% of the budget). 6× = 6.5 bad minutes per 6-hour stretch. Those two thresholds are the entire alert scheme.

2. Two windows, one truth

A single window cannot do the job. Long windows ignore disasters (a 24-hour burn barely moves a 28-day graph until it is too late); short windows amplify noise (one retry storm at 3 a.m. pages a human for nothing). The fix is a pair: a fast window to catch the spike, a slow window to confirm it is real. The alert fires only when both agree:

• Fast window: 1 hour, threshold 14.4× (2% of the budget in an hour). Catches sudden regressions within the hour. Alone, it is flappy — so it never pages alone.
• Slow window: 6 hours, threshold 6× (6% of the budget in six hours). Confirms the burn is sustained. A one-minute blip never crosses it; a steady regression crosses it within hours.
• The pair rule: fast AND slow over threshold = page. Fast only = Slack note. Slow only = ticket. The pair is what turns a noisy metric into a trustworthy one: false alerts need to defeat two independent windows at once.
• The slow-burn tier: 1 day, threshold 1×. If you are merely on pace, that is a weekly review item, not an alert. If a 24-hour window crosses 2×, open a ticket — a chronic drip will empty the budget without any single dramatic hour.

3. Thresholds you can defend in a review

• Page threshold: 14.4×/1h AND 6×/6h. The numbers come from the standard SRE scheme (2% of budget per hour, 5% per six hours) and they have a property worth saying out loud: they fire early — a page at 14.4× means ~2 days of budget remain, so the on-call is being woken to save the month, not to read its obituary.
• Ticket threshold: 2×/24h (and slow-only 6×/6h if the fast window missed it). Tickets mean “reliability debt is accumulating; look within a day.”
• Never alert below 1×. A green-trending budget is not a page. If your alerts fire when you are doing fine, the fix is the threshold, not the humans.
• Alert on the budget's timeseries, not the raw error rate. Compute the SLI's bad-event counter into “budget minutes spent, projected to window end” and alert on that. A raw 0.4%-error-rate alert will flap with traffic; a burn rate normalizes spending against time, which is what you actually decide on.

4. Wiring it (one afternoon, not one quarter)

• You need one good counter. The SLI's “bad events” counter with real weight — the same good-test the SLO definition wrote down. If the counter is fake (status-code 200s counted as good when the cart was empty), the burn rate is fake at a higher frequency.
• Four expressions. spend_1h / (B/672) ≥ 14.4; spend_6h / (6·B/672) ≥ 6; spend_24h / (24·B/672) ≥ 2; and the pair condition (fast AND slow). Every monitoring system that can do a rate-over-window can do this.
• Label the alert with the arithmetic. The page itself should say: “Checkout SLO burning at 16× — 7 of 121 budget minutes spent, projected breach in ~26h if unchanged.” An on-call who can read the stakes in five seconds makes a better decision than one who opens three dashboards.
• Route by tier, announce the flip. Pair-fire goes to the pager; slow-only goes to a ticket; 24h-drift goes to the weekly review. If a threshold gets tuned after a flap, say so in the channel — silent tuning is how a team stops trusting its own alarm.

5. Worked example

A twelve-person SaaS, checkout SLO 99.7% → 121 budget minutes per 28 days. Saturday 14:00, a config change ships a regression that burns about 3 budget-minutes per hour. At 14:45 the 1-hour window crosses 14.4×; by 16:15 the 6-hour window crosses 6× — the pair fires, and the on-call gets one page with the projection line. He rolls back at 16:25. Total damage: 7 of 121 minutes. The month survives; the error budget policy never triggers; the post-mortem is a ten-minute doc about a bad config value.

The counter-example is the same regression, same Saturday, at a team with no burn alerts: the raw error rate sits under the alert threshold all weekend (0.4% < 1% alert line), the 28-day graph looks flat, and by Monday the budget has spent 40 minutes and the policy pause lands mid-sprint with no culprit and no graph that shows the moment it started. The difference between the two Saturdays is not discipline. It is an alert on the pace instead of the total.

6. Metrics

• Every SLO row has burn-rate alerts wired: 100% — a budget without a pace alarm is an autopsy waiting to happen.
• Pair-flap rate: <1 page per week false-fire; every flap produces a recorded threshold decision, never a silent mute.
• Median budget remaining at page time: ≥80% — the alarm's whole job is firing while the month is still saveable.
• Window-end surprises: 0 — no breach should ever be discovered at the end of the window; the alerts should have said so days earlier.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit — incident response for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $49

Related: the SLO definition template sets the bar these alerts watch, the error budget policy decides what happens when the budget burns through, and the paging policy decides which human the pair-fire wakes.

Related: the four golden signals — the four golden signals define the latency and error rows those alerts watch.