Multiwindow Burn-Rate Alerts and Why a Short Window Also Suppresses

A burn-rate alert is an inequality: consume budget faster than some threshold over some lookback, and someone gets paged. Every simple version of this rule fails at one of two extremes. Make the lookback short and the alert fires on noise, because a handful of failed requests inside a two-minute window can imply a burn rate of several hundred. Make the lookback long and the alert fires promptly enough only for failures that persist for hours, by which point a total outage has consumed a large fraction of a thirty-day budget.

The standard resolution pairs two lookbacks in a single rule: a long window that establishes significance, and a short window that establishes that the condition is still current. Both must be true at the same instant. The mechanism is simple and the consequences are not, because the short window does two different jobs and the second one is usually unmentioned.

The two-window conjunction

The rule has the form

long_ratio  > threshold  AND  short_ratio  > threshold

evaluated continuously, where both ratios are computed from the same numerator and denominator definitions over different lookbacks. Detection latency is dominated by the short window: the alert can fire only once the short window has fully filled with bad events, and only once the long window has accumulated enough to cross the threshold. Stability is dominated by the long window: isolated transients never accumulate enough weight in it.

A representative set of thresholds, expressed as fractions of a thirty-day budget, is 2% within one hour, 5% within six hours, and 10% within three days. Using $B \geq f \cdot W / t$ from error budget units and burn rate, those become burn-rate thresholds of about 14.4, 6, and 1 respectively. The first is the page, the last is a ticket.

The long window’s threshold is what makes a transient exempt. A minute-long burst of errors at 100% for a 99.9% service has a burn rate of 1000. Summed against a one-hour long window, that minute contributes an average ratio of about 1.67% and a burn rate of about 16.7 over the hour. It crosses the 14.4 threshold, so the long window alone does not screen it out. What screens it out is the short window: by the time the long window has accumulated the burst, the short window has cleared, and the conjunction is false. This is the mechanism the pairing actually relies on. The long window is not a noise filter; it is a slow integrator that gives the short window time to disagree.

The pairing also has a failure mode that follows from the same logic. An incident that oscillates, with errors present for part of each short window and absent for the rest, can keep the short term below threshold while the long term stays above it. Neither condition holds simultaneously and the alert never fires, even though the service is burning budget steadily. Narrowing the short window makes this worse, because a narrower window is easier to miss. Widening it makes transient suppression weaker. There is no setting that is optimal for both.

What happens after the alert fires

The second job of the short window appears at the end of an incident. Because the short window clears quickly, the alert deactivates as soon as the errors stop, well before the long window’s average has decayed below threshold. Without it, a single five-minute outage during a page-worthy burn would keep the alert active for a full hour, and the on-call engineer would be looking at a green system and an open page.

This property depends on how the alerting system evaluates the condition, and the details differ between systems. In several alerting engines, an alert fires when its expression evaluates true and remains active for a configured for duration, and it resolves when the expression becomes false. When a long and a short lookback are combined, the resolution is edge-triggered on the conjunction, so recovery is fast. An alerting engine that resolves by comparing the current value against a stored threshold rather than by re-evaluating the full expression will not have this behaviour unless the expression is written to make it happen.

The engineering consequence is that the alert’s true state should be checked by re-evaluating the whole conjunction, not by looking at the long-window series in isolation. A dashboard that graphs only the one-hour burn rate will show a large value for an hour after a five-minute incident, while the alert has already resolved. That mismatch generates its own confusion.

Why the thresholds cluster at 14.4, 6, and 1

The numbers are not conventions to be memorized. They fall out of choosing a fraction of budget and a lookback. Two percent in an hour is an emergency because it means the service would exhaust a month’s budget in roughly two days if sustained. One hundred percent of budget in three days means something is badly wrong but the response is not necessarily waking anyone at night. The gap between the two is where a page becomes a ticket.

The useful discipline is to pick the fractions and the lookbacks together, from the actual response capability. If the on-call rotation takes twenty minutes to acknowledge and another twenty to start mitigating, a detection threshold that fires only after an hour of total failure has already ceded more than an hour of budget. Conversely, a detection threshold that fires after two minutes of a partial degradation will page someone who cannot act on information that is still accumulating.

There is also a cost asymmetry between the tiers that the thresholds should reflect. A page that turns out to be unnecessary trains the recipient to ignore pages. A ticket that arrives a day late costs little in a stateful service and a great deal in a payment path where the failures are individually irreversible. The same threshold table should not be applied across both without reconsideration.

Ratio construction inside the rule

The threshold comparison is against a ratio, and the ratio must be built from counters that reset correctly. A failure counter that drops to zero on process restart produces a negative increase in a naive subtraction, and a negative numerator makes the burn rate look better than reality precisely when a restart has occurred, which is often during an incident. The reset handling in counter functions — treating a decrease as a reset and taking the new value as the increment — is what keeps the numerator non-negative. A rule that subtracts raw samples without that handling will under-report errors exactly when a restart has happened.

The denominator must be the count of valid events under the same exclusion rules as the numerator, computed the same way. A rule that counts all requests in the denominator but only application-level requests in the numerator understates the error ratio by exactly the fraction excluded. If two percent of traffic is health checks that never fail, the reported error ratio is 98% of the true one, and every threshold is effectively 2% higher than intended.

Aggregating the ratio rather than the counters is the other common error. Summing per-instance error ratios and dividing by the instance count weights a silent instance equally with a busy one. The ratio must be formed after summing the numerator and the denominator across instances. The ratio form defined in the SLI ratio: numerator, denominator, and measurement point is what makes this possible, and the ordering matters most when instance counts change during an incident, which is exactly when autoscaling responds to the load pattern that caused it.

The sparsity floor

At low request volume, a burn-rate rule cannot work at all, and this is a structural limitation rather than a tuning problem. A one-hour window holding $n$ requests resolves the error ratio to $1/n$, so the smallest detectable burn rate at a 99.9% target is approximately $1000/n$. To detect the 14.4 threshold the window needs at least about seventy requests, which is satisfied by almost anything. To distinguish 14.4 from 6, the same window needs enough requests that the two thresholds are more than a resolution step apart, which pushes the requirement into the thousands.

The natural response is to extend the lookback for low-volume services, which is correct and moves the detection latency out by the extension. The alternative is to alert on a different quantity entirely: absolute failure counts, saturation indicators, or the ratio computed over a much longer period with the acknowledgement that fast detection is not available. What does not work is keeping the same rule and accepting that it flaps; a rule that fires and resolves repeatedly is indistinguishable from a broken sensor, and it consumes the attention that real pages need.

The interaction between volume and threshold choice is the subject of low-volume objectives and counting qualifiers, which treats the sample-size question directly. For high-volume services, the remaining risk in a multiwindow rule is not sensitivity but arithmetic: a rule with four thresholds, two lookbacks each, and a labels-matching clause has more places to be wrong than anyone will check during an incident, which is the argument for generating the rules from a single description of the objective.