Error Budgets

An error budget converts an SLO into a measurable allowance for unreliability over a defined period. Teams can use that allowance to balance reliability work against changes such as feature releases.

An error budget is derived from a service level objective (SLO). If an SLO requires 99.9% availability during a measurement window, the remaining 0.1% represents the allowed unreliability for that window.

The budget can be expressed as time, requests, or another appropriate unit. For example, with 99.9% availability over a 30-day period, the budget is 0.1% of the period, which is about 43.2 minutes.

A key benefit is that reliability becomes an explicit engineering constraint rather than an abstract goal. If a service is consuming its budget quickly, a team may prioritize reliability work; if substantial budget remains, the team has more room for changes that carry operational risk.

Error budgets are meaningful only when tied to a specific SLO and measurement window. They do not mean that every failure is acceptable, because the budget is an aggregate allowance and individual incidents can still violate other requirements such as latency, correctness, or contractual commitments.

Key points

• An error budget is the complement of an SLO.
• The budget must have a defined measurement window.
• It can be measured in downtime, failed requests, or another SLI-appropriate unit.
• Budget consumption can inform release and reliability priorities.
• An error budget does not replace incident response or other reliability requirements.

Interview questions

Can an error budget be based on something other than availability?

Yes. An error budget can be derived from an SLO for any measurable service characteristic where an appropriate SLI and target exist. For example, a service might define an SLO around request latency or successful request completion. The budget then represents the allowed amount of measurements that fall outside the target, according to the chosen SLI definition.

What is an error budget?

An error budget is the amount of unreliability allowed by an SLO during a defined period. For a 99.9% availability target, the budget is the remaining 0.1%. It gives engineers a quantitative way to discuss reliability and operational risk. Teams can use budget consumption when deciding whether to prioritize reliability work or proceed with changes.

How do you calculate an error budget from a 99.9% availability SLO?

First calculate the allowed failure percentage by subtracting the SLO from 100%, giving 0.1%. Then apply that percentage to the measurement window. Over 30 days, there are 43,200 minutes, so 0.1% corresponds to 43.2 minutes. The exact result depends on the chosen measurement window and how the SLI is defined.

What should a team do when it is consuming its error budget too quickly?

The team should investigate the causes of the reliability loss and consider prioritizing corrective reliability work. Depending on the team's operating policy, risky releases may be delayed or reduced while the budget is under pressure. The important point is that the response should be based on an agreed SLO and error-budget policy rather than an arbitrary feeling about reliability. Incident analysis and remediation can then address the underlying causes.

How would you explain the value of error budgets to a development team?

An error budget creates a shared quantitative framework for balancing feature delivery and reliability. Instead of treating reliability as an unlimited requirement, the team agrees on an SLO and uses its remaining budget as a signal of how much operational risk has been consumed. This can make release decisions more consistent and make reliability work easier to prioritize. The policy should still account for incidents, security, correctness, and other risks that an individual SLO may not capture.