Error budgets in SRE: balancing change and reliability

Measure the experience that matters

A running server does not guarantee that users can complete a task. For a web application, the share of valid requests served successfully can be one indicator; another service may need a latency indicator. Define measurement sources, request scope and what counts as good.

Choose a target appropriate to the use case. Discuss the value, complexity and operating effort involved rather than selecting a number simply because it looks impressive.

Calculate the budget in the same measurement unit

For a request-based model, multiply valid requests by the fraction outside the SLO. A 99.9% target across one million requests gives an illustrative allowance of 1,000 bad requests in the selected window.

This example counts requests; it is not a conversion to downtime. Time-based targets and multiple indicators need their own definitions rather than a sum of incompatible units.

Remaining budget = permitted bad requests − observed bad requests.

Agree policy before an incident

The Google SRE approach uses an error budget to establish common ground between change velocity and reliability. Agree what happens when consumption accelerates: review releases, reduce change scope or prioritize reliability work.

The policy should not be an automatic punishment. Distinguish routine changes from necessary fixes and identify who makes each decision.

Choose a window and monitoring process

Fixed and rolling windows reflect incidents differently. Document which data enters or leaves the calculation, how missing data is treated and when dashboards update. Relate measurements to releases to support investigation.

Alongside remaining budget, observe consumption speed to spot ongoing incidents. Test alert thresholds with the intended response workflow and on-call ownership.

Three ways to organize an error budget

These approaches help teams choose review windows and response rules. Keep SLI definitions, SLO targets and measurement units consistent; the organizational choice does not change the underlying measure.

• Threshold-based: agree actions at selected consumption levels, while also observing consumption speed.
• Fixed-period: evaluate within an agreed interval, such as a month. Make interval boundaries and incidents near those boundaries explicit.
• Rolling-window: recalculate over the most recent interval. Show denominators and time boundaries as older observations leave the window.

Introduce the approach incrementally

Start with one user journey, one definition set and an inspectable measurement source. Test calculations against historical data and known incidents before applying policy.

AQPTech can discuss a dashboard prototype and observability workflow within an agreed scope. The numbers on this page are illustrative and are not an AQPTech service SLA.