Error Budgets: The Currency of Reliability

WHY IT EXISTS: Because 100% reliability is an impossible and expensive goal, engineering teams need a way to balance shipping new features (which adds risk) against maintaining stability. Error budgets replace subjective debates with a data-driven framework for managing this inherent trade-off.

THE MENTAL MODEL: An error budget is the inverse of a Service Level Objective (SLO). If your SLO is to have 99.9% uptime, your error budget is the remaining 0.1%. Think of it as a literal budget of acceptable failures—errors, latency, or downtime—that you can "spend" over a period. It is the currency you use to pay for taking risks.

HOW IT WORKS: First, you define a Service Level Indicator (SLI), a direct measurement of performance like request success rate. Then, you set an SLO, a target for that SLI over time (e.g., 99.9% of requests succeed over 30 days). The error budget is simply 100% minus your SLO percentage. For a 30-day period, a 99.9% uptime SLO gives you an error budget of 43.2 minutes of downtime. As your service experiences outages or serves errors, you subtract that time from your budget.

WHEN TO USE IT: Use error budgets to empower teams to make autonomous decisions about shipping code. When the budget is healthy, teams are free to launch features or run experiments. When the budget is low or exhausted, all non-essential changes are frozen to focus on reliability. This creates a self-regulating system that aligns product and engineering on stability goals.

WHEN NOT TO USE IT: Error budgets are not suitable for systems where any failure is catastrophic, like medical device software. They are also less effective without mature monitoring capable of accurately tracking SLIs; a budget based on bad data is useless. Critically, never use an error budget to judge team performance; it is a planning tool, not a punitive measure.

ONE CANONICAL EXAMPLE: A payments API has a 99.95% availability SLO over a 28-day window. The error budget is 100% - 99.95% = 0.05%. Over 28 days (40,320 minutes), the team has 20.16 minutes of allowable downtime. A bad deploy causes a 10-minute outage, spending about half the budget. The SRE team can now make a data-driven decision to halt further releases for the week to preserve the remaining budget and prevent violating their SLO.