Burn Rate Alerting

A threshold alert asks "is the error rate above X right now?" — which is the wrong question in two directions. It fires on brief spikes that resolve themselves, generating noise, and it stays silent during a small sustained elevation that will exhaust the month's budget by the third week.

Burn rate reframes it: at the current error rate, how fast is the error budget being consumed relative to the rate that would exactly exhaust it over the SLO window? A burn rate of 1 means the budget lasts exactly as long as intended. A burn rate of 14.4 means it is gone in about two days.

Why it matters

It makes urgency proportional to consequence, automatically. A 5% error rate lasting two minutes and a 0.2% error rate lasting two weeks may consume identical budget; the first should page and the second should not, and burn rate over multiple windows distinguishes them without anyone tuning a threshold.

It also connects alerting to the objective that was actually agreed, so the alert fires when the users' experience is at risk of breaching the commitment, rather than when an arbitrary technical number moves. The alert and the SLO stop being two independent opinions about what "bad" means.

Implementation patterns

• Multiple windows evaluated together. A canonical configuration: a fast burn (a high rate over a short window, e.g. an hour) pages immediately, and a slow burn (a lower rate over a long window, e.g. six hours or a day) opens a ticket.
• A short secondary window as a confirmation on each alert, so a spike that has already ended does not page — this is what removes most of the noise, and it is the detail most often omitted.
• Rates derived from the budget arithmetic, not chosen by feel: pick the fraction of budget you are willing to spend before being notified, and the burn rate follows.
• Alert on the SLI at the user's vantage point, including timeouts and client-observed failures.
• Per user journey rather than per service, since a journey crossing five green services can still be failing.
• A ticket path that is genuinely worked, or slow burns accumulate unaddressed and the mechanism degrades into a page-only system with a silent backlog.
• Documented burn-rate context in the alert itself — remaining budget, time to exhaustion at the current rate — so the responder knows the stakes without opening a dashboard.

Industry example

The multi-window, multi-burn-rate approach is set out in Google's SRE workbook and has been widely adopted as the default recommendation for SLO-based alerting, including in Prometheus and Grafana-based stacks where it is now a standard recipe.

Its adoption is usually driven by alert fatigue rather than by theory: an organisation drowning in threshold alerts finds that replacing them with a small number of burn-rate alerts per journey reduces page volume by an order of magnitude while catching more of what matters — because the noise was concentrated in exactly the transient spikes burn rate is designed to ignore.

Failure scenarios

• A single window, which forces a choice between fast detection and low noise and gets neither.
• No short confirmation window, so alerts fire on spikes that have already resolved.
• An SLO that is wrong, which makes every derived alert wrong — burn rate inherits the SLO's quality entirely.
• SLIs measured server-side only, so client timeouts never consume budget and the alert stays silent through a real outage.
• Per-service SLOs, hiding a broken cross-service journey.
• Slow-burn tickets never worked, turning the mechanism into a paging system with an ignored queue.
• Burn-rate alerts added alongside all the existing threshold alerts, so the noise problem is unchanged and the practice is judged a failure.

Trade-offs

Burn-rate alerting requires a well-defined SLO and a correctly-measured SLI, which is real work and is the reason many teams never adopt it. Where the SLO is guessed, the alerting is guesswork with more arithmetic.

It is also less direct than a threshold, and responders need to understand it — a page saying "burn rate 14× over one hour" is less immediately legible than "error rate is 5%" until the team is fluent, and the transition period generates confusion.

And it deliberately does not fire for short spikes, which is correct and occasionally uncomfortable: a brief severe event that consumed little budget produces no page, and someone will ask why. The answer — that it did not threaten the objective — is right, and it needs to have been agreed in advance.

The trade is setup cost and conceptual overhead in exchange for alerts whose urgency matches their consequence. For a team with meaningful SLOs it is the correct default; for a team without them it is the second step, not the first.

Interview question

"We page on error rate above 1% for five minutes and on-call gets fifteen pages a night. Rewrite this as burn-rate alerting — tell me the windows, where the numbers come from, and what we will stop being paged for that someone will complain about."