Google SRE Chapter 5 — Eliminating Toil

We planted the seed of "toil" back in Chapter 1; now the book gives it a chapter of its own. This is probably SRE's most everyday, most hands-on idea.

What Toil Is, and How to Spot It

Google looks at several criteria to decide whether a piece of work counts as toil. If a task has most of the following traits, it's toil:

• Manual: it's done by hand.
• Repetitive: it happens over and over, not once.
• Automatable: a script or tool could do it; it doesn't actually require human judgment.
• Tactical, not lasting: it fixes the problem in the moment but doesn't improve the system for good.
• Grows with the service: as the system scales, so does this work.
• Adds no enduring value: once it's done, nothing lasting is left behind.

Manual deploys, answering the same kind of ticket by hand, adjusting capacity manually. All of it fits this definition.

Why Toil Is Genuinely Harmful, Not Just Tedious

Google frames this as a multi-sided problem. Toil stalls career growth, since time spent on it eats into time that could go toward learning and building. It's demoralizing, since repetitive work saps motivation. And the most critical part: since toil scales with the service, if left unchecked, a team eventually finds all its time going to toil with no room left for lasting improvement. It's the same crisis we talked about in Chapter 1 with the old sysadmin model.

The 50% Rule: An Alarm, Not a Target

The "toil shouldn't exceed 50%" rule from earlier chapters becomes operational here. Google treats it not as a goal to aim for but as an alarm signal: if a team's toil consistently runs above 50%, that's a sign of a structural problem, either the team isn't getting enough investment in automation, or it's simply being assigned the wrong kind of work.

Zero Toil Isn't Always the Right Answer Either

There's an interesting balance Google strikes here. Eliminating toil completely isn't always the right call. A small amount of it can be how newcomers learn a system. And sometimes the cost of automating something is higher than the cost of just doing it by hand, especially for rare, one-off tasks. This calls for an actual cost-benefit judgment; trying to automate every last bit of toil can turn into its own form of toil.

Closing Thoughts

Chapter 5 lays out one of SRE's most concrete, most measurable ideas: define toil, measure it, and reduce it systematically. This one idea underlies the automation and release engineering chapters that follow later in the book.

Through a 2026 Lens: Eliminating Toil With Code

Reading this chapter today, what stood out most was this: the entire Infrastructure as Code and GitOps movement is really an industry-wide implementation of this chapter's thesis. Anyone working with Terraform, Crossplane, or ArgoCD is, without necessarily thinking of it this way, putting "eliminate toil through automation" into daily practice. A decade ago this was an internal Google habit; today it's the standard workflow at companies of every size.

The more interesting question is how AI is shifting this equation. The book notes that automation can sometimes cost more than the toil itself, particularly for rare, one-off tasks not worth scripting. But AI-assisted tools, Claude Code, Copilot, and the like, are changing that cost-benefit balance at the root: writing a script now takes minutes instead of hours. Which raises a real question. Did a lot of the work that was "not worth automating" in 2016 quietly become automatable in a few minutes by 2026? Probably yes, and that suggests the very definition of toil needs to keep shrinking over time; some tasks considered "impossible to automate" yesterday don't even qualify as toil anymore.

One caveat is worth adding, though: AI can create a new kind of toil of its own. Reviewing AI-generated automation code, verifying it, and fixing its mistakes is arguably a new category the book never anticipated, something closer to "AI toil."

Next time, I'll move on to Chapter 6: Monitoring Distributed Systems.

Thanks for reading.