Error Budgets

An error budget is the permitted amount of failure implied by a service-level objective (SLO). A service-level indicator (SLI) measures actual behavior, such as the proportion of valid requests that succeed or complete within a latency threshold. The SLO sets the required performance over a defined measurement window. For a proportion-based SLO, the allowed bad-event fraction is one minus the target good-event fraction. The remaining budget is the allowed amount of bad events minus the bad events already observed within that window.

For example, an API with a 99.9% successful-request SLO can tolerate 0.1% failed requests. If the evaluation window contains one million eligible requests, its allowance is 1,000 failures. After 700 failures, 300 remain. For a time-based availability SLO measured continuously over 30 days, 99.9% permits 43.2 minutes of unavailability. These examples are not interchangeable: request-based measurement weights failures by traffic, whereas time-based measurement weights them by duration. Define eligibility, measurement boundaries, timeout behavior, and exclusions before using either calculation.

A service-level agreement (SLA) is a customer-facing commitment that may specify remedies such as service credits. An SLO is an operational target and is often stricter than the corresponding SLA, leaving a margin for intervention. Error budgets usually derive from SLOs rather than directly from contractual thresholds. An application's SLA also does not automatically match the SLA of its cloud infrastructure. Dependency failures, deployment defects, configuration mistakes, and application behavior all affect the customer experience, while provider SLA calculations have their own scope and exclusions.

In cloud operations, teams collect user-relevant telemetry and calculate budget consumption over a calendar or rolling window. Burn rate compares the observed bad-event fraction with the fraction allowed by the SLO. With a 99.9% SLO, a 1% failure rate represents a burn rate of 10. If sustained under comparable traffic conditions, that rate consumes the budget ten times faster than planned. Alerts across short and long windows help distinguish a brief spike from sustained degradation and provide time to intervene before the objective is missed.

A documented error-budget policy connects these measurements to decisions. Healthy remaining budget can support normal releases and controlled experiments. Rapid consumption may trigger rollback, smaller deployment batches, or incident response. Exhaustion commonly pauses discretionary changes while the team addresses reliability, but security fixes and recovery changes may remain permitted. These actions require explicit ownership and automation; monitoring alone does not enforce a release policy.

Error budgets also guide architecture choices. Multi-AZ deployment, redundant dependencies, tested failover, and automated recovery can reduce consumption, but add cost and operational complexity. Cross-Region recovery may be justified by business requirements rather than by an availability percentage alone. Evaluate recovery time and data-loss requirements separately because an availability budget does not define an acceptable recovery point. A budget is neither permission to cause avoidable outages nor a guarantee of customer satisfaction: aggregate success can hide severe failures for one tenant or critical workflow, so segment important journeys and review incidents even when the overall SLO is met.