An SLO like "99.9% available per month" can be measured two ways: by counting requests, or by counting time. This page walks through the time-based version, the one behind most error-budget dashboards and alerts, by building a month up from its smallest piece: a window.
Time-based SLOs don't look at individual requests. They chop the month into fixed-length windows and ask each one a single yes/no question: was this window good? Rows are days, columns are the time of day. Pick a window length; everything below is built on this grid.
An SLO of 99.9% means at least 99.9% of the windows must be good. The other 0.1% is the error budget. That's the whole definition: the budget is a count of windows, which is why it's usually quoted in minutes.
Every window has a success rate: the share of its requests that succeeded. The window is good when that rate is at or above a threshold, and bad otherwise. The threshold is a separate dial from the SLO. The threshold judges one window; the SLO counts how many windows failed that judgement. Drag the rate across the line.
Now put incidents on the calendar. Each one pushes the success rate down for a stretch of time. Two of these last 15 minutes: one at 50%, one at 0%. Edit the rates. As long as an incident sits below the threshold, how far below changes nothing. Raise one above the threshold and it disappears from the bill.
The budget is a pool, not a streak. One long outage and the same minutes scattered as blips across the month cost exactly the same. Slide the amount of downtime and watch both months breach at the same moment.
A window is bad as a whole. A 3-minute blip inside a 5-minute window costs 5 minutes of budget; inside a 60-minute window it costs an hour, and if it straddles a boundary it costs two windows. The window's rate is the average over its minutes, so long windows also dilute short blips, which may or may not keep them above the threshold. Move the blip around.
Counting windows ignores how much traffic each one carried. A 30-minute outage at 3 AM and one at 3 PM are the same six windows, but very different numbers of failed requests. A request-based SLI (successful requests ÷ all requests) sees that difference; a time-based one doesn't. Slide the outage across the day. The second page follows this thread.
Real services track more than availability. With several SLIs, a window is good only when every SLI passes its own threshold. Below, a latency problem, an error-rate problem, and an availability outage never overlap in time, yet they all drain the same budget. Nothing compounds; the costs simply add.
Everything from above in one place. Load a scenario or build your own month.