An SLO window is the period an SLO is measured over. A calendar window, such as a calendar month, starts fresh on the 1st, so the error budget resets all at once. A rolling window, such as the last 30 days, moves forward continuously, so old failures drop out one day at a time and the budget never fully resets.
What is an SLO window?
Every SLO is measured over a period, called its window or evaluation window. “99.9% of requests succeed” means nothing until it says over what period: 99.9% over five minutes is very different from 99.9% over 30 days.
The window also sets the size of the error budget and decides when it resets. There are two common kinds: calendar-aligned and rolling.
How does a calendar-aligned window work?
A calendar-aligned SLO uses a fixed reporting period, such as a calendar month. For example, a 99.9% availability objective could be evaluated from November 1 through November 30.
At the start of the next period, the evaluation begins again with a new set of measurements, and the full error budget is available again.
How does a rolling window work?
A rolling SLO continuously evaluates reliability over the most recent period. For example, a rolling 30-day window evaluated on November 10 includes measurements from the preceding 30 days.
On November 11, the window moves forward, adding the newest measurements and dropping the oldest ones. The budget does not simply reset at midnight or at the start of a month.
One day later the Oct 12 spike leaves the rolling window and headroom returns. The calendar month keeps counting until Dec 1.
For a request-based SLO, both the number of eligible requests and the number of bad requests in the window set the current error-budget position. As older failures leave the window, the service regains headroom. As new failures enter, it uses more.
Rolling vs calendar window: comparison
| Rolling window | Calendar window | |
|---|---|---|
| Budget resets | Gradually, as old data leaves the window | All at once, at the start of each period |
| Reflects recent experience | Always covers the last full window | Covers little data early in the period |
| After a large incident | Counted for one full window, then drops out on a known day | Counted until the period ends, then forgotten |
| Matches customer reporting | Rarely | Usually: most SLAs are monthly or quarterly |
| Best for | Engineering decisions, release policy and alerting | SLA reporting and business reviews |
Many teams use both: a rolling window for the engineering SLO and its alerts, and a calendar window for the customer-facing SLA report.
How does an incident age out of a rolling window?
In a rolling 30-day window, failures from a large incident stay in the window for exactly 30 days. On the 31st day they all leave together, and the error budget they used returns in one step.
This makes the budget predictable: a team can see the date a past incident stops counting. It also means a service that had a bad day four weeks ago can look much healthier tomorrow without any change in its current behaviour, which is why the current burn rate matters as much as the budget left.
What is the problem with calendar windows?
Calendar windows create a cliff. A team that exhausts its budget on the 28th has a full budget again on the 1st, whether or not the underlying problem was fixed. A team that has a major incident on the 2nd carries it for the whole month.
Early in a calendar period there is also little data, so a few failures can swing the SLI sharply. Rolling windows avoid both effects, which is why engineering SLOs usually use them.
How long should an SLO window be?
- 28 or 30 days is the most common choice for engineering SLOs. A 28-day window holds exactly four weeks, so every weekday is counted the same number of times.
- 7 days gives faster feedback, but a single incident can use a large share of a small budget.
- A quarter suits planning and business reviews, but reacts slowly.
The window length also changes alerting. Burn-rate alert thresholds are calculated from the window, so a 28-day and a 30-day SLO need slightly different values. Multi-window burn-rate alerting shows the calculation.
Frequently asked questions about SLO windows
Does an error budget reset every month?
Only with a calendar-month window. A rolling window never resets all at once: old failures leave the window one day at a time as new measurements enter.
Which is better, a rolling or calendar SLO window?
Rolling windows are usually better for engineering SLOs and alerting, because they always reflect the most recent period and have no reset cliff. Calendar windows are better for customer reporting, because most SLAs are measured per month or quarter.
Why do some teams use a 28-day window instead of 30 days?
A 28-day window contains exactly four weeks, so every day of the week is represented equally. A 30-day window can include five of some weekdays, which skews services with weekly traffic patterns.
Can a service use both window types?
Yes. Many teams run a rolling 28- or 30-day window for the engineering SLO and its alerts, and report a calendar-month figure for the customer SLA.
How does the window affect burn rate?
Burn rate is measured against the pace that would use the budget exactly over the window. Alert thresholds, such as 14.4× over one hour, are derived from the window length, so they change if the window changes.
Key takeaways
- Every SLO needs a window; the window sets the size of the error budget and when it resets.
- Calendar windows reset all at once at the start of each period.
- Rolling windows move forward continuously, so old failures leave gradually.
- Rolling windows suit engineering SLOs and alerting; calendar windows suit SLA reporting.