Error Budget Calculator

Subtract the SLO from 100% and multiply by the window. For time-based availability at 99.9% over four weeks: 0.1% × 40,320 minutes = 40.32 minutes, or 40 minutes 19 seconds. For a request-based SLO, multiply by request count instead: 0.1% of 3 million requests is 3,000 permitted failures. Both are the same calculation over a different denominator, which is why this calculator offers both.

An SLI is the measurement — the proportion of requests that succeeded, or the fraction of time the service was up. An SLO is the target you set for that measurement, such as 99.9%. The error budget is what the SLO leaves over: 100% minus the SLO, expressed as an amount of failure you are permitted to spend. An SLA is different again — it is the contractual version, usually looser than the SLO so that missing the internal target does not immediately cost money.

The SRE Workbook says both are valid and that the choice matters: a rolling window "is more closely aligned with user experience", because a large outage on the last day of a month is not forgotten on the first day of the next one, while calendar windows "are more closely aligned with business planning". It recommends an integral number of weeks, and specifically warns that a 30-day window contains four weekends in some periods and five in others — so if weekend traffic differs from weekday traffic, the SLI moves for reasons that have nothing to do with reliability. Four weeks rolling is the default here for that reason.

It is the agreement, written down in advance, about what happens as the budget is consumed — who decides, what changes, and at which thresholds. Google publishes a chapter on exactly this. A typical policy freezes non-critical releases when the budget is exhausted and returns engineering effort to reliability until the window rolls over. The value is that the decision is made calmly, before the outage, rather than argued during one.

Whatever your policy says. The common answer is a release freeze on anything not itself a reliability fix, held until the window rolls forward or the underlying problem is fixed. It is worth being explicit that this is the mechanism working rather than a punishment: the budget was spent on shipping, which is what it was for.

Time-based is easier to explain and matches how availability is usually promised. Request-based is more honest for a high-volume API, where a brief partial failure and a total outage are very different events that a minutes-of-downtime figure would score identically. Teams running both typically use availability for incident reporting and success ratio for the alerting thresholds.

Then the SLO is probably too loose to be constraining anything, and reliability effort is going somewhere it is not needed. Either tighten the target or deliberately spend the budget on faster iteration and riskier experiments. An objective that is never in tension with anything is not doing any work.

That is a policy choice and both conventions are in use. Some organisations exclude planned maintenance on the grounds that the SLO measures unplanned unavailability; others count everything, on the grounds that users cannot tell the difference. Pick one, write it down, and apply it consistently — the comparison between windows is only meaningful if the rule did not change.