Objective Windows: Rolling Windows, Calendar Months, and Time Equivalence

An objective without a window is incomplete. “99.9% available” over what period? A single hour, a day, a month, a year? The target and the window together determine the permitted amount of failure, and changing the window changes the quantity even when the percentage is held fixed. A 99.9% target over a year permits 8 hours and 46 minutes of unavailability; over thirty days it permits 43 minutes and 12 seconds. The same digits, a difference of roughly a factor of twelve.

There is a second, less obvious effect. The window determines not just how much failure is permitted but how that failure is distributed in time, because the boundary rule decides whether the counter resets, slides, or never resets. Two systems with identical traffic, identical targets, and identical failure patterns can have different budgets available on a given morning purely because of how their windows are maintained.

The three window types and what each measures

A rolling window of length $W$ evaluates the objective over the interval $(t - W, t]$ for every instant $t$. It has no boundary and therefore no reset. Its budget regenerates continuously, at a rate of one window’s worth per window, and its value depends on the last $W$ of history and nothing earlier.

A calendar window evaluates over a fixed interval that begins and ends on a schedule boundary: a calendar month, a week, a quarter. Inside the window it behaves like a rolling window over the elapsed portion; at the boundary it discards everything and starts over.

A fixed-sliding window, sometimes called a period window, is a calendar window shifted to an arbitrary phase: the fourth of the month to the third of the next, or Tuesday to Monday. It keeps the reset behaviour and moves the boundary to a convenient point.

The differences are visible in three questions that come up constantly. Does an incident at the end of the period still count against the service? Under a calendar window, the answer is no once the boundary passes, and the incident becomes invisible to the budget within a day. Under a rolling window, it continues to count for a full window length. Can a service recover from a bad period? Under a calendar window, yes, all at once. Under a rolling window, only gradually, as the bad hours age out of the interval. Can a service fail its target and then immediately pass? Under a calendar window, yes, trivially and without any change in behaviour.

Why twenty-eight days is the common default

Published guidance on objectives recommends a window of four weeks. The reasons are practical rather than theoretical.

A month of 28 days is exactly four weeks, so every window contains the same number of each weekday. A calendar month does not: it may contain four Mondays or five, and Monday traffic patterns differ from Saturday’s. Over a calendar month, the ratio is weighted differently depending on which days happen to be included, which makes comparisons between months noisy for reasons that have nothing to do with reliability. A 28-day window removes that source of variance.

Twenty-eight days is also short enough that a policy can act on it. A budget that takes a year to exhaust cannot constrain a decision made this quarter. It is long enough to average over weekly cycles, so a nightly batch job that reliably degrades latency for a few hours shows up as a small and predictable consumption rather than as a weekly crisis.

Thirty days is the other common choice, and it is worse on the first count and identical on the second. It is conventional because billing cycles are monthly and because dashboarding tools default to it. There is no strong reason to prefer it over 28 days, and the weekday-aliasing problem is real.

Note that ISO 8601 does not define “month” as a fixed duration; it distinguishes durations in calendar units from durations in time units precisely because a month is not a constant. A specification that says “within 30 days” and one that says “in the previous month” name different intervals, and systems that conflate them will produce different answers on the first of the month.

Equivalence between time and requests

The relationship between a time-based objective and a request-based one is exact under one strong assumption and approximate otherwise. That assumption is that traffic and failure are independent: the rate at which requests arrive does not depend on whether requests are succeeding.

Under that assumption, the fraction of requests that fail equals the fraction of time during which a randomly chosen request would fail, and the conversion is

$$\text{budget in time} = (1 - \text{SLO}) \times W$$ $$\text{budget in requests} = (1 - \text{SLO}) \times \text{total requests in } W$$

Both give 43.2 minutes and 0.1% respectively at 99.9% over thirty days. The request form is the more honest one for a service, because it charges for impact rather than for clock time.

The assumption fails in a specific and common way. When a service degrades, clients retry, and retries are requests too. A partial outage that makes every request take three seconds instead of fifty milliseconds can increase request volume by a large factor while increasing the failure count proportionally. Under the time-based view, that incident cost the same as any other thirty minutes. Under the request-based view, it cost far more, correctly reflecting that more users were affected.

The reverse failure also occurs. A service that fails hard and fast may shed load at the front door, so failed requests never arrive and never enter the denominator. The request-based budget is then under-charged, while the time-based view correctly records that the service was down. Neither form dominates; the choice depends on whether the failure mode of interest is degradation or unavailability.

A third conversion is needed when an indicator is measured in time directly rather than derived from request counts. A batch pipeline that must complete within a deadline can be scored as the fraction of runs that met it, which is a request-form ratio over runs rather than over individual jobs. The window then determines how many runs contribute, and a pipeline with one run per day gives a 28-day window exactly 28 samples. At 99% that target permits zero missed runs, which is a target that cannot be met in the sense of tolerating any failure at all. Low sample counts and tight targets interact badly, and the interaction is the whole of low-volume objectives and counting qualifiers.

Budget regeneration and the shape of recovery

A rolling window regenerates budget at a constant rate equal to the full budget divided by the window, but only after the window has been fully occupied with history. A service that starts fresh has a full budget immediately, because the interval contains no failures. That is the correct behaviour for a new service and an incorrect one for a service that has just been running for a long time in a broken state and is switched onto the objective: the interval is empty on day one, and the budget is full regardless of reality. Backfilling the window from historical telemetry, or running in shadow mode for one full window before enforcing, avoids the artifact.

Under a calendar window, recovery has a step shape. The budget is exhausted near the end of the month and returns to full at the boundary. This produces a specific pathology: work scheduled for the last days of a period is deprioritized because the budget is gone, and work scheduled for the first days is approved because the budget is fresh, even though the system is identical on both days. The policy has decoupled from the system and attached itself to the calendar.

A hybrid used in practice is to keep the rolling window for alerting, where continuous evaluation matters, and a calendar window for reporting, where the reset is convenient for stakeholders. The two numbers will never agree, and the disagreement must be documented, since a stakeholder comparing a monthly report against a rolling dashboard will otherwise conclude that one of them is wrong.

Window length changes what counts as an incident

A short window is more responsive to transient failures and less tolerant of them. At 99.9% over one day, the budget is 86.4 seconds; a single five-minute outage exhausts it several times over. At 99.9% over a year, the same five minutes is under 1% of the budget. Identical events, opposite conclusions.

This is the mechanism behind a well-known complaint about short-window objectives: they make everything an emergency. The complaint is usually misdirected. The problem is not that the window is short but that a short window is being used to justify a policy written for a long one. A daily objective is a reasonable thing to alert on and an unreasonable thing to gate a quarterly roadmap on.

The inverse error is quieter. A very long window makes every individual incident look negligible, so no single event justifies action, and the service declines slowly through a sequence of events that were each individually acceptable. The burn-rate framing in error budget units and burn rate is what catches this, because a sustained small burn eventually crosses any long-window threshold.

Windows in the query layer

Computing a rolling ratio exactly requires retaining every event for the full window or maintaining a structure that can answer interval queries. Most metrics systems approximate it by summing per-bucket counts over a fixed lookback, and the fidelity of the result depends on the bucket width and on how the lookback is aligned.

A PromQL-style query that sums a counter increase over a lookback window evaluates the window as a set of sample boundaries rather than as a true interval. Querying at an arbitrary instant picks up the samples that fall inside the range, which produces a value that depends on sample alignment, not only on the underlying events. The distortion is small at high sample rates and arbitrary at low ones, and at low rates it compounds with the sampling limits described in low-volume objectives and counting qualifiers.

The practical constraint is simpler: whatever window is chosen, it must be expressible in the storage system with acceptable fidelity, and it must be the same window in the alerting rule, the dashboard, and the policy document. Three slightly different windows is the most common cause of an objective that two people describe differently in the same meeting.