Rolling Error Budget Window

A team breaches its 99.9% monthly target on the 29^th after a bad deploy. On the 1^st the dashboard is green, the budget is full again, and the change that caused it ships in the next release. Three months later the same regression is still shipping, and the objective has recorded it every time without ever preventing it.

The window shape, not the target, decides whether an objective changes behaviour. A calendar window forgives on a fixed date that everyone learns, so the cheapest time to take a risk is the end of the month. A rolling window forgives 28 days after the event, which is the behaviour a budget is supposed to produce.

Why it matters

99.9% of a 30-day month is 43 minutes and 12 seconds; 99.99% is 4 minutes and 19 seconds. Those are the quantities a release decision is made against, and under a calendar window they are reset by the calendar rather than by recovery. A rolling window also removes the artefact where the first week of a month always looks healthy, which is when risky work tends to be scheduled by accident rather than by intent.

The second effect is operational. A rolling budget is always current, so detection stops depending on a review cadence, and "how much budget is left" becomes a number on a dashboard instead of a finding in a monthly meeting.

Implementation patterns

• Use 28 days rather than 30. Whole weeks keep weekday seasonality constant, so the budget does not move because the window happens to contain five Mondays.
• Compute it as one ratio over the window: good events divided by valid events across the whole 28 days. Averaging 28 daily availability figures weights a quiet Sunday the same as a Monday peak and produces a different, wrong number.
• Precompute daily buckets of good and valid counts and sum them for the window. A 28-day ratio evaluated directly over raw counters is an expensive query to run on every dashboard refresh.
• Keep burn-rate alerting separate and short. The 28-day window is for the release decision; 1-hour and 6-hour burn windows are for paging. They answer different questions and conflating them gives you an alert that arrives days late.
• Publish both views. Report the rolling budget for engineering decisions and a calendar-month figure where a contract or a board pack requires one.

Industry example

Burn-rate alerting over multiple simultaneous windows is the published site-reliability practice, and in production it assumes a budget that is continuously evaluated rather than reset. A payments platform of the kind that must hold a monthly contractual credit typically ends up running both shapes: a rolling 28-day budget that governs whether features ship, and a calendar-month computation that feeds billing credits.

Failure scenarios

• The cliff. A single bad hour dominates the budget for 28 days and then drops out abruptly, so a release freeze lifts itself at midnight with no human judgement involved. Make the exit a decision, not an arithmetic side effect.
• History changes under you. Backfilled or corrected data moves events into a window that was already closed, so a budget that was spent becomes unspent. Pin the inputs or state explicitly that recomputation is allowed.
• Low volume. On a service with a few thousand requests a month, a 28-day ratio is still dominated by noise, and a couple of failed requests can read as a breach.

Trade-offs

When not to use it

When the objective exists to compute a contractual credit, the billing period is the window and nothing else is defensible. Avoid it also on services whose event volume over 28 days is too small for a ratio to be stable: a count-based objective, or a longer window with a wider target, is the honest instrument there. And on a service launched last week, any window is measuring the launch rather than the system.

Interview question

Q: Your organisation has monthly availability objectives that have never paused a release. What would you change first, and how would you know it worked?

What a strong answer covers: the window shape and the incentive it creates; replacing per-service targets with a small number of journey objectives; stating the target in minutes rather than nines; separating burn-rate paging from the budget decision; and naming the evidence that it worked, which is a release actually held and a product owner who can state the remaining budget in minutes.

Quick check

Quiz: Why 28 days rather than 30 for a rolling window? — Whole weeks hold weekday seasonality constant, so the budget does not move with the number of Mondays in the window.

Flashcard: What does a calendar-month budget teach a team that nobody ever writes down? — That risk is cheapest at the end of the month, because the budget resets on the 1^st regardless of recovery.