A single burn-rate window either pages too late on slow leaks or too eagerly on brief blips. We run two windows at once and it fixed both problems.

A single-window burn-rate alert forces an uncomfortable tradeoff: a short window catches fast burns but flaps on noise, a long window is stable but misses the incident until half your budget is already gone.

Why one window isn't enough

We initially alerted on a 1-hour window at 14x burn rate — sensitive enough to catch outages fast, but it also fired on five-minute blips that self-resolved before anyone could act. Widening to a 6-hour window fixed the flapping but meant we sometimes didn't page until 35% of the monthly budget was already spent on a slow, steady degradation.

Two windows, one alert

We now require both a fast window and a slow window to agree before paging: a short window confirms the burn is real right now, a long window confirms it isn't a blip. This is the standard multi-window, multi-burn-rate pattern, and it cut false pages by more than half while catching slow burns days earlier than the single long window did on its own.

from slo_burn("checkout-api")
| extend fast = burn_rate(window=1h), slow = burn_rate(window=6h)
| where fast > 14 and slow > 6
| project _time, fast, slow, service

Tune thresholds from budget math, not gut feel

The burn-rate multipliers aren't arbitrary — they're derived from how much budget a sustained burn at that rate would consume in the alert's window relative to the SLO period. We keep a small reference table per service so new SLOs get sane starting thresholds instead of everyone re-deriving the math from scratch.

A short window for recovery, too

The same fast window that confirms a burn is real also tells us when it's over — once the short window drops back under threshold while the long window is still elevated, we downgrade the page to a lower-urgency notification instead of leaving it open at full severity. That distinction between "still actively burning" and "recovering but budget already spent" changes what the responder should be doing next.

  • Never page on a single burn-rate window alone — pair a fast and a slow window.
  • Require both windows to agree before triggering the page.
  • Derive burn-rate multipliers from budget math, not intuition.
  • Keep a per-service threshold reference table so new SLOs start from a sane default.
  • Downgrade severity once the fast window recovers, even if the slow window is still elevated.