Toil

The SRE Book's definition of toil, why measuring it is hard, and how the 50% cap actually works.

Overview

A precise term

Toil is one of the SRE Book's most precise terms. Ch 5, verbatim:

"Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows."

Each adjective matters

Misapplying any one of them sweeps in work that isn't toil.

1. Manual — Done by hand — Tasks already automated
2. Repetitive — The same task many times — Novel design, one-off projects
3. Automatable — Could be automated — Irreducibly human work: design, judgment calls, customer interactions
4. Tactical — Interrupt-driven, not strategic — Planned engineering projects
5. Devoid of enduring value — Service unchanged after you do it — Code changes that improve the system
6. Linear scaling — Grows as the service grows — Bounded work

Examples

Manually restarting flaky services — Overhead: meetings, planning, training
Granting database access on Slack request — Engineering: writing code, designing systems
Rotating expired certificates by hand — Investigation: debugging novel, one-off problems
Scaling instances before traffic spikes — Customer interactions: support escalations

Also toil: resolving false-positive alerts, and onboarding new services to monitoring by hand.

The 50% cap (SRE Book Ch 5)

SRE teams cap toil at 50% of total time. The other 50% goes to engineering: automation, monitoring improvements, capacity planning, postmortem follow-ups.

Engineering compounds — Hours spent on automation save hours forever
Toil grows with scale — Without a cap, growth eats SRE capacity until it's 100% toil
Toil burns people out — SREs who only do toil leave or disengage

> [!IMPORTANT] The cap is a team-wide rolling average over a quarter, not a per-person, per-week target. Incident weeks run heavy; the quarterly trend is what matters.

Measuring toil

Weekly self-reported time tracking — Honest but imprecise
Ticket-based: count interrupts and average resolution time — Misses untracked work
Quarterly survey: "what % of last week was toil?" — Directional
Instrumented toil sources (the 2026 approach) — Counters of manual restarts, manual cert rotations, dismissed false-positive alerts; time derived from them. More objective

When the cap is exceeded

Reduce toil — Find the largest sources and automate them
Shift toil — Hand it back to the dev team that owns the underlying problem. SRE's leverage: "keep producing toil for us and the pager comes back to you"
Reduce ownership — If toil can't be reduced, drop the service

Key concepts

Toil definition (verbatim): "Manual, repetitive, automatable, tactical, devoid of enduring value, and scales linearly as a service grows." — SRE Book Ch 5.
50% toil cap: SRE team-wide rolling average. Other 50% is engineering. Without the cap, growth eats SRE capacity — death spiral.
Linear scaling: Toil grows with the service. 10× the service = 10× the toil. The signature property — bounded work isn't toil.
Engineering work: The 50% that isn't toil. Automation, monitoring, capacity planning, design. Compounds over time.
Hand-back: When toil is unfixable, SRE returns ownership to dev. SRE's leverage: "produce more toil for us → take the pager back."

When to use it

Quarterly SRE team review — what % of capacity went to toil?
Capacity planning — which services produce the most toil? Engineer those down first
Hand-back conversations — when toil is unfixable, the SRE team hands the service back to dev
Hiring justification — toil at 70% means we need automation investment, not more SREs

Interview questions

Define toil and walk me through the six properties.
How does the 50% toil cap actually work in practice?
Give me a concrete example of identifying and eliminating toil.