What is toil?
Engineering culture and software practice
Toil is a term from site reliability engineering, defined in Google's 2016 SRE book, for the manual, repetitive, automatable operational work that keeps a running service alive but creates no lasting value and grows as the service grows. It is deliberately measured so it can be capped and reduced. Google's rule is that such operational work should stay below fifty percent of an engineer's time, leaving room for work that removes the drudgery for good.
What this means
Toil is the busywork of running something. Every live service needs occasional hands-on attention: restarting a stuck process, clearing a full disk, running the same script after every release, copying numbers into a report. None of it is hard. None of it improves anything. It just has to be done, again and again, and there is more of it every time the thing you are running gets bigger.
The reason engineers gave this a name is that it is easy to miss. Toil looks like work, feels like work and fills a working day, yet it leaves nothing behind. Naming it lets a team point at it, count it and decide it is too much. That is the whole purpose of the word: not to complain, but to make an invisible drain visible enough to argue about with a number attached.
Toil is not the same as difficult work, and it is not the same as chores. Google's own definition is careful about this. Some grungy tasks have lasting value and so are not toil; some administrative tasks are unavoidable overhead rather than toil. Toil is specifically the automatable, value-free repetition that scales with the size of what you run.
Why it matters
Toil matters because it is the work that quietly stops an organisation building anything new. If the people who could be improving a service spend their days keeping it upright by hand, capacity for improvement approaches zero. The service does not fall over, but it never gets better either, and the people doing the work burn out. Google frames excessive toil as a direct cause of slower feature delivery, lower morale and higher staff turnover.
The same shape appears far outside software. A finance team that rekeys the same figures between two systems every month, an operations manager hand-building the same board report, an administrator copying form responses into a spreadsheet: all of this is business-process toil. It is manual, repetitive, automatable and it grows with the organisation. The reason the SRE framing is useful to a non-engineer is that it gives you permission to treat that work as a problem to be removed rather than a fact of life.
There is a direct link to any decision about automation, including automation using AI. The business case for automating a task is essentially a toil calculation: how much repetitive effort does this consume, how much would removing it cost, and does the sum come out ahead over a sensible period. The Google workbook is explicit that this arithmetic should include indirect benefits such as reduced burnout and less context-switching, not just hours saved.
AI sharpens the point in both directions. Generative tools can absorb a great deal of repetitive drafting and lookup work, which is real toil reduction. But they also create a new kind of toil: someone has to read, check and correct the generated output, and if that review is itself manual, repetitive and endless, you have simply moved the drudgery rather than removed it. Busy is not the same as building.
How it works
Where the term came from
The word in its technical sense was formalised in the 2016 O'Reilly book Site Reliability Engineering: How Google Runs Production Systems, in the chapter "Eliminating Toil" written by Vivek Rau. The chapter defines toil as work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as the service grows. Not every task has all six attributes; the more it has, the more it is toil.
The book pairs the definition with a management rule: Google's SRE organisation aims to keep operational work below fifty percent of each engineer's time, so that at least half is spent on engineering that reduces future toil or adds features. Google reports that quarterly surveys of its own SREs show average time spent on toil of about thirty-three percent, below the fifty percent ceiling, though with wide variation between individuals. The idea spread through independent channels: a peer-reviewed USENIX ;login: article, "Invent More, Toil Less" (Fall 2016), recapped Rau's definition and added a Bigtable case study, and the 2018 collection Seeking SRE, edited by David N. Blank-Edelman for O'Reilly, carried the concept into a wider set of organisations.
Toil versus overhead versus engineering work
The distinctions are the useful part. Overhead is administrative work not tied to running the service: meetings, paperwork, goal-setting. It is not toil, and automating it away is not the point. Engineering work is work that produces lasting value: building the automation, redesigning the process, deleting the need for the task. Toil sits between them, and the test is whether the task requires human judgement or is a rote response that a script or a rule could handle. Cleaning up a messy alerting configuration is grungy but has lasting value, so it is engineering, not toil.
Finding it and measuring it
You cannot cap what you cannot see. The standard approach is to survey the people doing the work every quarter, asking roughly what fraction of the last month went on toil, and to cross-check that against on-call logs, ticket queues and time tracking. Google's published sample survey asks engineers to estimate their toil fraction and to name toil they could automate but have not, because the very toil leaves no time to automate it. That last question exposes the trap that makes toil self-perpetuating.
How experienced teams reduce it
There are three moves. Automate the task so a machine does it. Offer self-service so the person who needs the thing can get it without a human in the loop. Or delete the work entirely by removing whatever generates it, which is the cheapest reduction of all and the most often overlooked. The warning that comes with all three is that automation can create fresh toil: a fragile script that needs constant babysitting, or a tool that pages a human every time it runs, can consume more effort than the manual task it replaced.
Examples
Consider a professional services firm of forty people. Every month an analyst exports data from three systems, pastes it into a master spreadsheet, fixes the formatting and emails a report to partners. It takes two days and errors creep in. This is textbook business-process toil: manual, repetitive, automatable, no lasting value, and it grows as the client list grows. The firm times it, finds it costs roughly twenty-four days a year, and decides a one-off automation project that takes eight days to build is plainly worth it.
A software team of eight runs a service that needs a manual restart whenever memory fills up, roughly twice a week, often out of hours. Each restart is five minutes but the interruption and the on-call anxiety cost far more. Logging the interruptions for a month shows the pattern. Rather than automate the restart, which would hide the underlying fault, the team fixes the memory leak and deletes the work. That is the preferred move: eliminate the cause, not paper over it.
A charity adopts an AI assistant to draft grant-reporting summaries, expecting to save time. It does save drafting time, but a programme officer now spends every afternoon checking each summary for invented figures and tone. The charity has reduced one kind of toil and created another. Recognising the review as toil in its own right, it narrows the tool to a few well-defined report types where checking is quick, rather than letting it generate everything.
Common misunderstandings
The first misconception is that toil means work you dislike. It does not. The SRE definition is explicit that preferences vary and some people enjoy repetitive work; toil is defined by its characteristics, not by anyone's feelings about it. Enjoyable repetitive work that scales with the service is still toil.
The second is that toil should be driven to zero. The book argues the opposite: small amounts of toil are fine, and chasing zero can cost more than it saves. The point of the fifty percent figure is a ceiling, not a target of nothing.
The third is that toil is the same as technical debt. It is not. Technical debt is accumulated design cost, the deferred cleanup of shortcuts taken in how something was built; it is paid down by refactoring and redesign. Toil is recurring operational drag, paid down by automating, self-servicing or deleting the repeated task. A system can carry heavy technical debt yet generate little toil, or run cleanly yet still demand constant manual attention. Related folklore terms are distinct too: yak-shaving is a chain of prerequisite tasks blocking one goal, and bit-rot is the slow decay of unmaintained systems, whereas toil is steady, repeating operational work.
The fourth is that automation always removes toil. Automation that is fragile, noisy or needs constant supervision simply converts one form of toil into another, which is why the reduction has to be measured after the fact, not assumed.
Risks and boundaries
The main risk is treating the fifty percent figure as a law of nature. It is Google's chosen ceiling for its own engineers and its own scale; it is not a benchmark that transfers unchanged to a ten-person business. The useful transfer is the discipline of putting an upper bound on repetitive operational work and measuring against it, not the specific number.
A second boundary is that not everything repetitive is worth automating. The cost-versus-benefit analysis in the workbook exists precisely because some toil is cheaper to tolerate than to remove, especially rare tasks or ones about to disappear for other reasons. Labelling every dull task as toil to be eliminated can itself become a low-return project that drifts from what the business needs, a drift USENIX authors warn about explicitly.
The live debate concerns AI and operations. Machine learning has long been pitched as the way to automate away operational toil, but a 2020 USENIX ;login: article by Google engineers cautioned that this is often harder than it looks and can introduce new failure modes. The honest position is that AI is both a toil reducer and a toil creator, and which one dominates depends on how much human checking the output demands.
What to do next
Start by making toil visible. Ask the teams doing operational and administrative work to estimate, for a typical month, what fraction of their time goes on manual, repetitive tasks that produce nothing lasting. A rough number beats no number, and the act of asking usually surfaces the worst offenders immediately.
Set an upper bound and defend it. Decide what share of a team's time is acceptable to spend on this work, and protect the rest for improvement. Without a protected margin, toil expands to fill the available time, which is exactly the failure the fifty percent rule was invented to prevent.
Prefer deletion, then self-service, then automation, in that order. The cheapest win is removing whatever generates the task; the next is letting people serve themselves; automation is powerful but carries the risk of creating fresh toil, so budget for maintaining whatever you build.
When you weigh an automation or AI case, count the review work. If a tool produces output that a person must check line by line forever, include that ongoing checking in the sums. A tool that halves drafting time but adds an afternoon of verification may not be the win it appears to be.
FAQs
Is toil the same as any boring job?
No. Toil has specific traits: it is manual, repetitive, automatable, tactical, produces no lasting value and grows with the service. Boring work that requires human judgement, or that has lasting value, is not toil.
Where does the fifty percent figure come from?
From Google's 2016 SRE book, which caps operational work at half an engineer's time so the other half can go to engineering that reduces future toil. It is Google's ceiling, not a universal standard.
Does toil only apply to engineers?
No. Rekeying data, hand-building recurring reports and copying information between systems are business-process toil with exactly the same shape, and the same case for removal.
How do I measure toil if I do not track time closely?
Start with a simple quarterly estimate from the people doing the work, cross-checked against ticket queues and recurring calendar tasks. Precision matters less than making the drain visible.
Should I try to eliminate all toil?
No. Small amounts are fine and cheaper to tolerate than to remove. Aim to cap and reduce it, not to reach zero.
Does AI remove toil?
It can, but it can also create new toil in the form of checking generated output. Measure the reduction after adoption rather than assuming it.
How is toil different from technical debt?
Technical debt is deferred design cost, paid down by redesign. Toil is recurring operational effort, paid down by automating, self-servicing or deleting the task.