Reducing Toil
What counts as toil
Toil is work that is manual, repetitive, automatable, tactical, devoid of enduring value, and scales linearly with service growth. All the properties matter. A one-off migration is manual and tactical but not repetitive, so it is not toil. Writing a runbook entry you will never use again is not toil. Responding to the same alert with the same fix every week is textbook toil.
The SRE response is to measure it, cap it, then engineer it away. Many organisations set an explicit toil budget (commonly ≤50% of an SRE's time, matching the 50% engineering rule) and track toil via ticket categories, pager volume and time surveys. The goal is containment and steady reduction, not zero: some manual judgement always remains, and premature automation of a process you do not yet understand creates new toil in maintenance.
Traps
- Defining toil as ‘work I dislike’. It is a structural property of the task, not a personal preference.
- Assuming all manual work is toil. Debugging a novel outage is manual, high-value and non-repetitive.
- Believing automation is always a win. Unmaintained scripts, snowflake tooling and over-fitted automation become their own toil source.
- Ignoring the toil created by automation itself (pipeline upkeep, flaky tests, alert noise).
Worked example
A team of four SREs logs 160 person-hours a week. Of that, 96 hours go to certificate rotations, manual deployments and ticket-driven access grants - 60%, above the cap. The team's first action is not a big rewrite but a toil register: which tasks recur, how often, how long. The top three recurring tasks usually account for most of the hours, and one quarter of dedicated engineering time typically removes a large share of them. Track hours saved per sprint as the metric of success.