Embracing Risk: Reliability Is a Budget, Not a Goal

WHY IT EXISTS Chasing 100% reliability for a service is not only impractical but often harmful. The cost of each incremental improvement in reliability grows exponentially, both in redundant hardware and in opportunity cost, as engineers focus on stability instead of new features. Furthermore, users often cannot perceive the difference between high and extreme reliability, making the investment pointless.

THE MENTAL MODEL Treat reliability not as a number to maximize, but as a budget. Your availability target, or Service Level Objective (SLO), defines an "error budget"—the amount of downtime the business has agreed is acceptable. This budget is a resource to be spent on taking calculated risks, like launching features, performing maintenance, or experimenting. Having too much budget left over is a signal that you are being too conservative and slowing innovation.

HOW IT WORKS An SRE team works with the business to set an explicit availability target, like 99.99%. This creates an error budget of 0.01%. As long as the service is operating within its error budget, the team is free to approve new releases and other changes that carry some risk. If the service exceeds its error budget (i.e., has too much downtime), all risky changes are frozen, and the team's focus shifts exclusively to improving reliability until the budget is back in good standing.

WHEN TO USE IT This framework should be used for nearly any service to facilitate an explicit, data-driven tradeoff between reliability and feature velocity. It aligns engineering efforts with business goals by converting an abstract desire for stability into a concrete metric that guides day-to-day decisions on what to ship.

WHEN NOT TO USE IT The philosophy of embracing risk is about making intentional choices. It's not that the framework is inapplicable, but that for certain critical systems, the business may decide the cost of near-perfect reliability is justified. In such cases, the availability target would be extremely high (e.g., 99.999%), resulting in a tiny error budget that reflects a business decision to tolerate almost no risk.

ONE CANONICAL EXAMPLE A user on a 99% reliable smartphone network cannot tell the difference between a service that is 99.99% available and one that is 99.999% available. Their experience is dominated by the least reliable component in the chain—their own connection. Spending millions to achieve that extra "9" of service reliability is wasted if the user can't perceive the benefit.