# Use multi-window burn-rate alerts instead of raw threshold pages

> Design SLO alerts around error-budget burn with paired short and long windows so you catch fast outages and slow burns without paging on harmless spikes.

Canonical URL: https://www.devobs.io/articles/multi-window-burn-rate-alerts/
By: Ines Costa
Published: 2025-08-09T12:11:08.894Z
Updated: 2026-09-06T10:18:15.722Z
Section: Architecture

Page when a service is consuming its error budget fast enough to threaten the SLO, not whenever a raw metric crosses a convenient line.

Reviewed: 2026-09-06 UTC.

A multi-window, multi-burn-rate alert asks two questions at once: is the budget disappearing quickly right now, and has that behavior lasted long enough to justify waking someone?

## Start from the budget

For a 99.9% availability objective over 30 days, the allowed bad fraction is 0.1%. Burn rate is the observed bad-event fraction divided by that allowance. A rate of 1 consumes the budget exactly over the objective period. A rate of 14.4 would consume it in about 2.1 days if sustained. This normalization lets the same alert design apply to request success, latency, or another ratio-based SLI.

The [Google SRE Workbook chapter on alerting on SLOs](https://sre.google/workbook/alerting-on-slos/) develops multi-window, multi-burn-rate alerting and explains how burn rates relate to budget consumption. Use its structure as a starting hypothesis, then test thresholds and window lengths against your traffic and incident history. Do not alert directly on the remaining monthly budget: one old incident can keep that signal low long after the service is healthy.

## Pair fast detection with persistence

Create a fast-burn page with a short window and a longer confirmation window. One workable pattern is to require a high burn rate over both a very short window and a longer confirmation window. The short window detects a sharp outage quickly. The longer window helps prevent a single bad scrape or tiny burst from paging. Both conditions should be true before you wake someone.

Create a slower page or urgent ticket with longer windows at a lower burn rate. For one candidate design, try pairing a medium window with a several-hour window and backtest it against incident history. This can catch a [partial failure in API aggregation](https://www.devobs.io/articles/partial-failure-api-aggregation/) that misses the fast-burn page but still consumes budget quickly enough to matter. Route even slower budget consumption to a ticket reviewed during working hours. The goal is not to represent every anomaly on the pager.

Calculate ratios from matching populations. If the numerator is failed API requests, the denominator must cover the same routes, regions, and time window. Exclude health checks only if both sides exclude them. For low-volume services, request counts may be too sparse for a five-minute-style signal; lengthen the short window or alert on a direct catastrophic condition such as no successful jobs.

## Keep alerts actionable

An alert should identify the SLO, current burn rates for both windows, affected dimensions, budget remaining, and a dashboard or service runbook. [Prometheus alerting guidance](https://prometheus.io/docs/practices/alerting/) recommends keeping alerting simple, alerting on symptoms, and avoiding pages where there is nothing to do. Page on user-visible SLO consumption, then use dependency, saturation, and deployment signals for diagnosis.

Model the rule as recorded time series before embedding a large expression in every alert. Record good events, valid events, their ratio, and burn rate with consistent labels. Be careful with `for`: the long-window condition already encodes persistence, while an additional long `for` delays detection and complicates reset behavior. A short `for` can still protect against evaluation gaps.

Test the rule by replaying three shapes: a complete outage, a 2% failure lasting several hours, and a one-minute spike. Record time to fire and time to clear. Ensure missing traffic does not quietly produce a healthy ratio; handle absence as its own condition when traffic is expected.

## Decide the response before rollout

For each alert tier, write the intended action. A fast-burn alert pages the primary and may trigger rollback investigation. A slow-burn alert may page during staffed hours or create an urgent ticket. Capacity forecasts, isolated customer errors, and dependency warnings should stay diagnostic unless they consume the service SLO.

Take one noisy threshold alert and map its failures into the SLO numerator and denominator. Backtest paired windows against the last month of data, then replace the page only after the new rule catches known incidents without reproducing the old noise.

## Source references

- <https://sre.google/workbook/alerting-on-slos/>
- <https://prometheus.io/docs/practices/alerting/>