What is toil?
Toil is manual, repetitive, automatable work that adds no lasting value and scales with team size rather than output. It is the status report assembled by hand every Friday, the server restarted for the hundredth time, the spreadsheet re-keyed from another spreadsheet. Untoil defines it as the work your company does to stay in place.
The term was formalized by Google's Site Reliability Engineering book, which defines toil as work that is "manual, repetitive, automatable, tactical, devoid of enduring value," and that "scales linearly as a service grows." A task does not need every attribute to qualify. The book's test is sharper than the list: if a machine could do the task just as well, or the task could be designed away entirely, it is toil. If human judgment is essential, it probably is not.
Google SRE Carla Geisser put the whole idea in one sentence: "If a human operator needs to touch your system during normal operations, you have a bug." Swap "system" for "process" and the sentence describes most companies.
What counts as toil, and what does not?
The six attributes from the SRE book: manual, repetitive, automatable, tactical, without enduring value, and growing linearly with scale. The everyday version is simpler. As the monitoring company OneUptime puts it: "If it feels like 'this again,' it's probably toil."
Three neighbors get mistaken for it. Overhead, like payroll or planning meetings, is administrative work that does not track headcount the way toil does and often cannot be designed away. Tech debt is the future rework a shortcut creates; toil is the recurring manual work that unpaid debt generates, which is why the two spiral together. And judgment work that merely repeats, like reviewing designs or interviewing candidates, is not toil at all: the repetition is not the problem, the automatability is.
How much does toil cost?
More than almost anyone measures. The numbers that exist are consistent and ugly:
- Google's quarterly surveys put average SRE toil at about 33 percent of working time, inside an organization that caps it at 50 percent and staffs specifically to fight it. Most companies do neither.
- Harness's survey of 500 engineering leaders and practitioners found 52 percent of developers name burnout as a primary reason peers quit, and estimates automation could reclaim 740,000 hours a year for every 1,000 developers. Harness CEO Jyoti Bansal's framing: "If you can reduce toil, you can reduce burnout, which in turn positively impacts your bottom line."
- One engineering lead's published account measured 35 hours of toil per engineer per week, roughly $300,000 a year for one team, before automation cut it to 5.
- Writing in Forbes, DevZero cofounder Debo Ray connects toil to the top reported drivers of workplace unhappiness: lost productivity, lost autonomy, and work whose impact nobody can see.
The arithmetic scales viciously because toil grows with headcount:
What does one recurring task cost a year?
Very. A team of 100 losing just 20 minutes a day is like having 4.0 full-time employees doing nothing but toil, all year.
Team Members
Min per day each
8,333
Hours lost per year 🤦
What does toil do to a team?
The most honest writing on this is not in vendor blogs, it is in the threads where operators talk to each other. A widely shared r/devops post titled "How toil killed my team" describes engineers resolving the same failing service for years by SSHing in and restarting it, calling toil "a tax on innovation" and landing on the line that explains the whole pattern: "They weren't lazy—they were fatigued." One reply distilled a decade of retention research into eleven words: "Toil is the No. 1 cause of burnout. Not too much work."
The SRE book names the same damage from the employer's side: career stagnation for the people stuck doing it, low morale, attrition of exactly the engineers you most want to keep, and a slow breach of faith with everyone hired to build. As LeadDev summarizes the org-level symptom: everybody is busy, but nothing is getting done.
Why does toil persist?
Because each instance is individually cheap. Restarting the server takes two minutes; fixing the reason it crashes takes two days nobody has. The SRE book warns that toil left unchecked "can quickly fill 100% of everyone's time," and the r/devops thread shows the end state: "just restart it" hardens into company policy, and the team stops believing fixes are possible.
The counterargument deserves airing, because it is why many smart teams do nothing. When the SRE chapter hit Hacker News, the most upvoted skepticism was practical: "Why spend 5 minutes manually toiling on a task, when you can spend 6 hours failing to automate it?" Commenters told of automation projects that never paid back, and of manual work that beat the flaky automation meant to replace it. The lesson is not that toil is fine. It is that eliminating toil starts with knowing which toil is worth eliminating, which is a measurement problem before it is an automation problem.
How do you reduce toil?
- Find it and price it. Toil hides in threads, inboxes, and habits, not in dashboards. Until each recurring task has a number attached, in hours per year, prioritization is guesswork and the loudest complaint wins.
- Try to delete the task before automating it. The strongest move is designing the work away so nobody and nothing performs it. Automation is second best: it keeps the task alive with a machine attached, and machines need tending.
- Automate what survives, in cost order. Rank by annual hours and fix from the top. This is also the answer to the Hacker News objection: a priced list is what separates the 6-hour automation that pays back in a week from the one that never pays back at all.
- Keep measuring, because toil grows back. Google treats this as permanent gardening, not a project. Every new tool, hire, and workaround plants next year's toil.
What does toil look like in practice?
Three examples, priced in annual hours the way Untoil reports them.
Filing expense reports takes half a day
Every trip means re-typing receipts into the old expense portal, chasing approvals over email, and re-submitting the whole thing when one field is wrong.
Weekly status reports are copy-paste hell
Every Friday the whole team copies updates out of Slack and Jira into a doc by hand, reformats it, and pastes it into an email nobody reads.
Onboarding a new hire is 100 manual steps
Creating accounts, requesting access, and setting up tools is a checklist we redo by hand for every single hire across five different systems.
Where Untoil fits
Everything above converges on one gap: teams do not lack the will to fix toil, they lack the list. Untoil exists to produce it. Its AI agents read where work already happens, including Slack, Google Drive, and Microsoft Teams, surface the repetitive work inside, estimate each item's annual hours, and rank the whole backlog by cost. The finding and pricing steps, the ones nobody budgets for, run continuously on their own. If you lead operations, AI agents for COOs covers that side in depth.
Common questions about toil
- Toil or TOIL? Same word, opposite meanings
- If you searched this from the UK, you may mean TOIL, Time Off In Lieu: paid leave granted instead of overtime pay. That TOIL is a benefit. This page is about the other toil, the one nobody grants you. The two get mixed up often enough that a Reddit thread on r/sre exists mostly to untangle a published article that confused them. The memorable difference: TOIL is time your employer gives back. Toil is time your processes quietly take away.
- Where does the term toil come from?
- The modern usage comes from Google's Site Reliability Engineering book, published in 2016, which needed a name for operational work that is manual, repetitive, automatable, and devoid of enduring value. The word replaced older informal terms like busy work. Untoil borrows the name because the problem it describes was never limited to engineering.
- How much toil is acceptable?
- Google caps toil at 50 percent of each SRE's time and measures roughly 33 percent in practice. Practitioner guidance is stricter for most teams: under 20 percent of team time is a common target, and sustained levels above 35 percent are a crisis. The honest answer is that nobody knows their real number until they measure it.
- Is all repetitive work toil?
- No. Work that requires human judgment, produces lasting value, or genuinely must be done by a person is not toil even when it repeats. Google's test: if a machine could accomplish the task just as well, or the task could be designed away entirely, it is toil.
- What is the difference between toil and tech debt?
- Toil is repetitive manual work that consumes time today. Tech debt is the future rework created by past shortcuts. They feed each other: unpaid tech debt generates recurring failures that become toil, and a team buried in toil never gets time to pay down the debt.
- Does toil only affect engineers?
- No. The concept was named in engineering, but manual data re-entry in finance, copy-paste reporting in sales, and checklist-driven onboarding in HR follow the same definition: manual, repetitive, automatable, and scaling with headcount instead of output. Untoil measures toil across the whole company for this reason.
Find out how much toil your company is carrying
Connect one workspace and Untoil returns a ranked, priced list of the repetitive work inside it. Untoil is invite-only while we onboard teams by hand.
Already have an invite? Sign in
Last updated August 27, 2026