Toil is manual, repetitive, automatable, tactical work that leaves nothing better behind and grows with scale. Find it by listing recurring tasks, then automate the ones that are frequent, scriptable and low risk first. Google aims to keep toil under 50 percent of an engineer's time because too much leads to boredom and burnout.
What counts
The SRE book's characteristics of toil:
- Manual. A person runs a script or clicks through steps.
- Repetitive. The same thing, again and again.
- Automatable. A machine could do it, or the need could be designed away.
- Tactical. Interrupt driven rather than planned.
- No enduring value. The system is no better afterwards.
- Linear growth. More services, more of the same work.
Not all operational work is toil. Judgment heavy investigation is not.
Why it matters for people
The book says too little project time slows career progress, and that excessive toil leads to low morale, burnout, boredom and discontent. Security staff are hired to think. Spending most of the week copying data between tabs wastes them.
Common security toil
- Triage of scanner findings that follow the same pattern
- Chasing owners for evidence at audit time
- Access review spreadsheets
- Opening the same ticket template for each advisory
- Rotating credentials by hand
- Re-checking whether a patched version exists
A simple scoring method
For each candidate task, note three things on a scale of one to five: how often it happens, how long it takes, and how safe it is to automate. Multiply them. Start from the top. This scoring is our suggestion, not from the source.
Order of attack
- Collect and enrich. Pull data together automatically. Low risk, big time saving.
- Route and ticket. Create tickets with the right fields and owner.
- Reminders and evidence collection. Nudge people, gather proof.
- Remediation. Highest risk. Keep a human approval step until you trust it.
Safeguard's autonomous remediation with fix pull requests follows that last principle: it is off by default, with every category set to Manual. Whatever tool you use, begin with approvals on.
Measure the result
Track hours of toil per week before and after. If the number does not fall, the automation is not working, or has become new toil to maintain.
Avoiding new toil
Automation can become a maintenance burden of its own. Every script needs an owner, a place in version control, and a plain description. If it breaks silently, it is worse than the manual task.
Make failures visible: have the automation report when it did not run. Review the list of automations twice a year and retire any that nobody uses. The aim is less repetitive work overall, not a pile of fragile scripts that only one person understands.
Quick check
Is all automation worth the effort?
No. If a task is rare, short or risky to automate, leave it manual and document it.
Sources
Last reviewed: 19 October 2026.
