Google SRE Chapter 3 — Embracing Risk

With Part II, the book moves past the infrastructure glossary and into SRE's real philosophical core. Chapter 3, to me, holds one of the book's clearest ideas: 100% reliability is the wrong target.

Why 100% Reliability Is the Wrong Target

It goes against intuition, but Google makes the case plainly: pushing a service from 99.999% toward 100% is both nearly impossible and economically pointless. The reason is simple — the cost of reliability doesn't scale linearly, it scales exponentially. Going from 99% to 99.9% is relatively cheap. Going from 99.99% to 99.999% can be enormously expensive: extra redundancy, extra infrastructure, extra engineering time.

There's a user-side argument too: most users can't actually tell the difference between 100% and 99.999%, because their own device and their own internet connection were never that precise to begin with. Buying that last sliver of a percent turns into an investment that makes no tangible difference to anyone in the real world.

Risk Tolerance Isn't an Engineering Question

The most important move Google makes here is this: "How reliable should this service be?" isn't really an engineering question — it's a business question. Figuring it out means asking things like:

• What level of downtime is actually acceptable for this service?
• Do different kinds of failure — a brief slowdown versus a full outage cost the same?
• How is that cost even measured? Lost revenue? User trust? Reputation?

Where the Error Budget Comes From

This is the heart of the chapter. If aiming for 100% is the wrong move, then you set a concrete target instead an SLO. Say, 99.9%. That target automatically creates an error budget: the remaining 0.1% is a deliberately permitted margin for risk.

The practical effect of this is powerful: as long as that budget isn't spent, the development team can ship new features, take risks, and experiment at whatever pace they want. Once the budget runs out, feature releases stop, and the whole team's focus shifts back to reliability. This mechanism turns the dev-versus-ops tension we talked about in Chapter 1 into something decided by an agreed-upon number rather than anyone's gut feeling a neutral referee.

Closing Thoughts

Chapter 3 lays out what might be SRE's most concrete and most quoted contribution: reliability stops being a vague "make it good" goal and becomes something measurable, negotiable, and crucially something that resolves the dev/ops tension into an actual budget. This single idea is the foundation everything in the SLO, monitoring, and alerting chapters is built on.

Through a 2026 Lens: How Well Does the Error Budget Hold Up in Regulated Industries?

What struck me most reading this chapter was comparing it against a culture I know firsthand from fintech and banking one that often runs in direct tension with it. In regulated industries, the pressure for "zero downtime" is real and concrete. Regulators, SLAs, and reputational risk all feed into an expectation of zero failure.

So does the error budget logic simply not apply there? A decade of hands-on experience gives a clearer answer: it applies, just in layers. In a regulated bank, not every system sits under the same SLO. The core system approving payments runs against a 99.99%+ target, while an internal reporting dashboard can live with a much looser budget. The concept of an error budget doesn't disappear it just scales with each system's criticality. Which, in a way, proves the book's own point: risk tolerance isn't an engineering decision, it's a business one. In regulated industries, a regulator largely makes that call for you; in unregulated areas internal tools, experimental features the engineering team gets to set its own budget.

There's a further step worth noting for 2026: observability tooling has matured to the point where tracking an error budget in real time, at a granular level, is far easier than it used to be. A decade ago, an error budget was something closer to a monthly or quarterly accounting line. Today, Prometheus/Grafana-based SLO dashboards can alert on burn rate within minutes. That means you're no longer waiting for the budget to run out — you can catch the trend early and act on it. That kind of visibility simply wasn't accessible when Google published this book.

Next time, I'll move on to Chapter 4: Service Level Objectives the SLI/SLO/SLA trio that gives the error budget its mathematical foundation. Thanks for reading.