The 50% Toil Cap

The six characteristics of toil, the 50% cap as floor-on-engineering, and the four-step legacy lifecycle.

Overview

What toil is

Toil is the SRE's anti-feature. SRE Book 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."

The six characteristics

Manual — Does a human have to run it?
Repetitive — Is it done again and again?
Automatable — Could a machine do it?
Tactical / interrupt-driven — Is it reactive rather than planned?
Devoid of enduring value — Is the service the same after it's done?
Scales linearly with growth — Does it grow with traffic or service count?

What toil is not

Overhead: meetings, training, HR paperwork, goal-setting — Necessary work that doesn't produce production value, but isn't toil
Grungy long-term work: cleaning up alert configs, migrating to a new database — Has enduring value

The 50% cap

Aggregate operational work, all of it (tickets, on-call, manual tasks), must stay at or below 50% of an SRE's time. The other 50% must be engineering.

> [!IMPORTANT] The Workbook treats this as "a guarantee, not just a cap": a floor on engineering time, not a ceiling on ops.

> [!TIP] Handing pages back to dev when the cap is breached is the explicit relief valve. It is a feature, not a punishment.

Key concepts

Toil: "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." (SRE Book Ch 5)
Six characteristics: manual / repetitive / automatable / tactical (interrupt-driven) / devoid of enduring value / scales linearly with service growth.
Toil vs overhead vs engineering: Toil = bad, eliminate. Overhead = necessary (meetings, HR), manage. Engineering = good, invest. Cleaning alert configs is engineering, not toil — it has enduring value.
50% cap: Aggregate operational work ≤ 50% of an SRE's time. The other 50% MUST be engineering that reduces future toil.
Legacy lifecycle: Workbook Ch 6: Avoidance → Encapsulation → Replacement → Retirement. The four-step pattern for replacing a manual process.
Engineer at source: The Workbook's preferred remediation: fix the cause of the toil, not the symptom. Don't script around the bug; fix the bug.

When to use it

Classifying a piece of work — is this toil, overhead, or engineering?
Defending engineering time against operational pressure
Justifying the temporary "give pages back to dev" lever when an SRE team is overloaded
Designing the legacy-replacement strategy for a manual process (Avoid → Encapsulate → Replace → Retire)

Interview questions

What's the difference between toil, overhead, and engineering?
My SRE team is at 70% operational work. What does the Workbook say?
Walk me through the legacy-replacement pattern.
How do you measure toil?