SLO Time Windows: Choosing Your Measurement Period

WHY IT EXISTS A service level objective (SLO) like "99.9% availability" is meaningless without a timeframe. Is that 99.9% per hour, per day, or per year? The time window provides this critical context, turning a vague goal into a measurable target that can drive data-informed decisions about reliability work.

THE MENTAL MODEL Think of the time window as the denominator for your reliability calculation. It sets the pace for your team's response and planning. A short window, like 7 days, is a weekly test where every outage is a significant event. A longer window, like 28 days, is a monthly report card that smooths out minor blips and focuses attention on sustained trends.

HOW IT WORKS Most SLOs are measured over a rolling window. For a 28-day rolling window, your compliance is calculated based on performance over the last 28 days. Each day, the oldest day's data is dropped and the newest day's data is added. This provides a consistent, up-to-date view of service health, unlike calendar months which vary in length. This consistency is key to making the data-driven tradeoffs between reliability and feature development that SRE practices are built upon.

WHEN TO USE IT The question is not if you use a time window, but which one to choose. A short window (7-14 days) is good for new services or features where you need a fast feedback loop on stability. The most common choice is a 28-day or 30-day rolling window, which balances responsiveness with the need for strategic planning, preventing knee-jerk reactions to every minor incident. This allows teams to maintain reliability in the medium-to-long term.

WHEN NOT TO USE IT This is more about which windows to avoid. First, avoid calendar months. A 1% error budget is a different amount of downtime in February (28 days) versus October (31 days), which complicates planning. Second, avoid windows that are too long (e.g., 365 days). You could burn your entire year's error budget in January and have no room for error for the next 11 months. Third, avoid windows that are too short (e.g., 24 hours), as this can cause alert fatigue and frantic, short-sighted fixes.

ONE CANONICAL EXAMPLE A web service has a 99.95% availability SLO over a rolling 28-day window. A 28-day period contains 40,320 minutes. The total allowed downtime (the error budget) is (1 - 0.9995) * 40,320 = 20.16 minutes over any 28-day period. If an incident causes 15 minutes of downtime, the team knows they have only ~5 minutes of budget left for the next few weeks, influencing their decision to delay a risky deployment.