Error budgets, a core Site Reliability Engineering concept popularized by Google, reframe “100% uptime” as the wrong goal entirely — a genuinely useful mental model for balancing reliability work against feature development.
The Core Idea
SLO (Service Level Objective): 99.9% uptime per month
Error budget: the remaining 0.1% - about 43 minutes of allowed downtime per month
If you're WITHIN budget: ship features freely, some risk is acceptable
If you've EXHAUSTED the budget: freeze feature releases, focus entirely
on reliability until back within budget
Why 100% Uptime Is the Wrong Target
Chasing 100% uptime has genuinely diminishing, often absurd returns — each additional “nine” of reliability (99.9% → 99.99% → 99.999%) costs disproportionately more engineering effort for less and less real-world benefit, especially once you’re already more reliable than most of your actual dependencies (cloud providers, DNS, the public internet itself).
The Genuine Value: A Shared, Objective Decision Framework
Error budgets give product and engineering a shared, data-driven way to decide “should we ship this risky feature now, or focus on stability first” — rather than that decision being a purely political or gut-feeling argument between teams with different, unstated priorities.