Toil is the manual, repetitive work with no lasting value that wears technical teams down: service restarts, disks to purge, account creation tickets, checks done by hand. The concept comes from SRE (Site Reliability Engineering) as defined by Google and applies to any team that operates a system in production, from the administrator of a Linux fleet to the platform team. This page gives you the precise definition of toil according to Google's six criteria, the 50% rule, a method to measure and prioritise it, concrete strategies to eliminate it for good, and a 2026 overview of what agentic AI really changes in the equation.
What you will learn
- Define toil according to the six criteria set by Google SRE and tell it apart from legitimate engineering work.
- Identify the toil hidden in your daily tasks and its usual sources on a server fleet.
- Measure your team's percentage of toil and prioritise its elimination by return on investment.
- Choose the right elimination strategy for the context: root cause, automation, self-service, refusal, uniformity.
- Automate without creating new risk, and avoid the mistakes that turn a script into new toil.
- Build a team culture that values automation instead of treating it as stolen time.
What is toil?
Toil is not simply "boring work" or "tasks nobody likes doing". It is a precise category of work, defined by Google in the "Eliminating Toil" chapter of its founding SRE book, then refined in the SRE Workbook chapter, which details the measurement method and the reduction strategies.
Toil is work tied to running a production service that has six characteristics:
| Characteristic | Description | Example |
|---|---|---|
| Manual | A human runs it, not a machine | Restarting a service by hand, copying files |
| Repetitive | Comes back regularly (not once a year) | Every Monday, every hour, at every deployment |
| Automatable | A script or system could do it | Checking logs, creating accounts |
| Tactical | Responds to a symptom, not a cause | Restarting a crashing service vs fixing the bug |
| No lasting value | Does not improve the system permanently | Once done, the system is no better |
| Grows with the system | More users/servers = more work | 10 more servers, 10 times the same maintenance |
No single criterion is enough on its own: a manual but unique task is engineering, a repetitive but already automated task costs nothing anymore. It is the combination that signals toil. Even if you have written a script, if you must launch it by hand every time, it is still toil: execution remains human. The last characteristic is the most toxic: it turns your team into a brake on the company's growth.
What does toil look like on a Linux server?
The SRE Workbook illustrates the definition with a case every administrator recognises: when the /tmp directory of a web server reaches 95% utilisation, an engineer logs in over SSH, hunts for superfluous log files and deletes them. The disk goes back down, the alert goes quiet, and everything starts again at the next fill-up.
The task ticks every box. It is manual (login, commands), repetitive (it comes back at every fill-up), automatable (a script would do the cleanup) and tactical (it treats the symptom). It has no lasting value, since the disk will fill up again, and it grows with the fleet: ten web servers, ten purges. The Workbook draws the lesson that the best outcome is not the purge script but a patch to the software so that it stops filling the disk.
The diagram below sums up the approach the page details: you identify toil, measure it, prioritise it, then eliminate it, and the 50% rule serves as an alarm signal on the measurement.
Why toil is toxic
Toil is not just "boring". Google's SRE Book describes its systemic effects on teams and organisations, and field experience adds others, well beyond the simple frustration felt in the moment.
-
Career degradation: engineers who spend their time on toil learn no new skills. Their CV stagnates while their colleagues progress.
-
Demotivation: repetitive work with no visible impact creates burnout and disengagement. People need to feel their work makes sense.
-
Inability to scale: if every new customer generates extra toil, the team becomes a glass ceiling. You cannot grow faster than your capacity to absorb toil.
-
Role confusion: a team meant to improve reliability that spends its days on chores ends up looking like a classic operations team, and nobody knows what is expected of it anymore.
-
A precedent that attracts toil: a team that readily accepts manual tasks encourages other teams to hand it even more, since the cost stays invisible to them.
-
Invisible technical debt: time spent on toil is not invested in improvement. Scripts are not written, processes are not automated.
-
Turnover: good engineers end up leaving for teams that automate. Nobody wants to spend their career restarting services by hand.
The 50% rule
Google SRE advertises a simple goal to keep the balance: keep operational work below 50% of each SRE's time. The rest must go to engineering work: design, automation, lasting improvement of the system. The SRE Workbook specifies that this ceiling covers all operational work, toil or not, and not only toil in the strict sense.
This limit is a ceiling, not a target. The SRE Book acknowledges that in small doses, toil is not harmful. Keeping a little operational work also keeps the team in touch with production: a team that never has its hands in the system ends up making decisions disconnected from operational constraints. The danger starts when toil eats into engineering time.
Above 50%, the team no longer has time to automate. It spends its time putting out fires instead of preventing them. Toil breeds toil: the less time you have to automate, the more toil piles up, until it fills entire days.
If your team regularly exceeds 50%, it is an alarm signal that must go up to management. It is not an "individual productivity" problem, it is a systemic problem that needs extra resources or a smaller scope.
In the field, the observed value usually stays below this ceiling. At Google, the quarterly surveys cited by the SRE Book put the average time spent on toil at about 33%. Outside Google, the 2026 Catchpoint SRE Report, based on more than 400 practitioners, measures a median toil of 34% of working time. Both figures confirm that the 50% rule is an upper alarm limit, not a goal to reach: aiming for a third rather than half leaves more room for engineering.
Identifying toil in your daily work
The first step to eliminate toil is to recognise it. It often hides behind habits: "we have always done it this way" usually masks a task that has never been questioned.
Ask yourself these 4 questions about your recurring tasks:
- Am I doing exactly the same thing as last week?
- Could a script do this for me?
- Would this task disappear if we fixed the root cause?
- Does this task double if the number of users doubles?
If you answer "yes" to several of these questions, it is toil.
Concrete examples
The following table compares tasks that look alike on the surface but belong to very different categories. The distinction lies in the lasting value produced, not in how tedious it feels.
| Task | Toil? | Why |
|---|---|---|
| Restarting a crashing service | Yes | Manual, repetitive, treats a symptom |
| Creating user accounts | Yes | Automatable, grows with users |
| Checking backups by hand | Yes | Monitoring could alert automatically |
| Answering password reset tickets | Yes | A self-service portal would remove the task |
| Investigating a new incident | No | Learning, improvement, not repetitive |
| Writing an automation script | No | An investment that removes future toil |
| Doing a code review | No | Knowledge transfer, lasting value |
| Documenting a process | No | Reduces future toil (fewer questions) |
Where does toil come from on a server fleet?
On a production fleet, toil almost always comes from the same four sources, which the SRE Workbook files in its taxonomy (business processes, production interrupts, release shepherding, migrations). Knowing them saves you from searching at random: you start from these families to fill in the toil log described below.
Recurring tickets are the most common source. The team manages a resource and handles internal users' requests one by one: creating an account and its permissions, adding a firewall rule, registering an application behind a load balancer (the component that spreads traffic across servers). The trap is invisible: the system "works" from the requesters' point of view, so nobody questions the process, and every satisfied request validates the channel and calls for more.
Production interrupts are the unplanned interventions that keep a service available without fixing its cause: freeing disk space, restarting an application that leaks memory, relaunching a service that no longer responds. They look legitimate because they are urgent and visible, and handling them fast is valued. That is precisely what makes them hard to remove: nobody thanks the engineer who made an on-call page disappear.
Manual deployments generate toil even with partial automation: a rollback done by hand when the new version causes trouble, an emergency patch applied in the middle of the night for lack of a process, the same setting changed on ten servers, one by one. Every manual step is a chance for error and a cost that comes back at every release.
Endless migrations look like one-off efforts, but the coexistence phase of the two systems often lasts months: both platforms must be fed, watched and reconciled in parallel. A migration with no firm cutover date and no planned decommissioning of the old system, whether a database, a move to the cloud or a change of configuration management tool, becomes a permanent burden.
Measuring toil
To eliminate toil, you must first quantify it. What is not measured does not improve, and individual intuition about "what takes time" often proves misleading.
The simplest method is to keep a toil log for two to four weeks, long enough to absorb month-end peaks and on-call weeks. Each team member notes the tasks done, the time spent, the frequency (daily, weekly, monthly), and whether it is toil according to the criteria above.
The measurement is built with the people who perform the tasks, as the SRE Workbook recommends: they are the only ones who know the micro-interventions that appear in no ticket. The Workbook also advises an objective unit, minutes or hours, rather than a ticket count whose duration varies. Keep this unit of measure from start to finish, and record it before, during and after your efforts: otherwise the comparison loses its value.
At the end of this period, calculate your team's percentage of toil. Divide the hours spent on toil by the total hours worked. If you get 60%, you have a serious problem. If you are at 30%, you have a comfortable margin, close to the median observed in the industry.
Then categorise your toil to prioritise. Each toil task can be rated on three axes. Impact measures the time you would save if the task disappeared. Effort measures how complex it is to automate. Risk measures the consequences of a human error in the task.
High-impact, low-effort tasks are your quick wins: automate them first. High-impact, high-effort tasks are your major projects: plan them over several sprints. Low-impact, high-effort tasks can wait or be ignored.
Calculating the return on investment
Before automating a task, two figures are enough: the automation cost (developing then maintaining the script) and the time saved, that is the frequency multiplied by the duration of the task. If the second exceeds the first over a reasonable horizon, usually a few months, automation is justified.
The direct calculation still underestimates the gain, because it forgets the indirect benefits. An automated task produces fewer human errors, hence fewer incidents. It improves team morale, which limits departures. And an automated process is a documented process, which speeds up onboarding.
Elimination strategies
Once toil is identified and prioritised, several strategies are available, from the radical cure to the minor adjustment. The SRE Workbook lists about fifteen of them; the table keeps those an operations team can apply the following week.
| Strategy | Description | Example |
|---|---|---|
| Remove the root cause | Fix the underlying problem | Fix the memory leak instead of restarting |
| Fully automate | A script/job replaces human intervention | Health check + auto-restart |
| Self-service | Hand the keys to users | Password reset portal |
| Reject the toil | Skip a task whose absence costs nothing | Batch low-stakes requests |
| Filter with SLOs | Ignore what does not threaten the service objective | Minor alert handled the next morning |
| Human interface first | Structure the request before automating | Form, then automation of frequent cases |
| Increase uniformity | Remove configuration variants | Servers rebuilt with Infrastructure as Code |
| Reduce the frequency | Go from daily to monthly | Automatic log rotation |
| Simplify | Reduce manual steps | 20-step runbook → script with 3 checkpoints |
Remove the root cause
Toil is often a symptom. The Workbook is explicit: the optimal strategy is to eliminate it at the source, by changing the system rather than handling its consequences in a loop. Before automating a task, ask whether the need itself can be removed.
If you restart a service every day because it leaks memory, the real solution is not to automate the restart, it is to fix the memory leak. The automated restart is a plaster; fixing the leak is a cure.
The Workbook reports a system administration case: disks were filling with gigabytes of logs produced by a modified network driver. Rather than automating the purge, the team traced the problem to its source, and a kernel patch made it disappear for good. An automatic purge would have hidden the defect, and every new server would have inherited it.
Fully automate
When the cause cannot be removed, a script, an automated job or a system configuration fully replaces human intervention, with no intermediate manual validation.
Take the example of a service that crashes from lack of memory. Today, you receive an alert, log in, restart the service. Tomorrow, you configure a health check that detects the problem and an auto-restart that relaunches the service without intervention. You have turned 15 minutes of repetitive toil into zero human intervention, until the cause is fixed.
Offer self-service
Sometimes, automation means handing the keys to users rather than doing everything yourself as the technical team. Self-service exposes the operation itself, no longer the request for an operation: the user triggers the action, and the system runs it with the service's rights, not the user's.
Password reset tickets are a classic example. Instead of handling each request by hand, deploy a portal where users can reset their password themselves. Same logic for a firewall rule or a service account: a form or a documented script that teams run without you. Your team moves from executor to owner of the guardrail: it defines what the automation accepts, refuses and logs.
No need to wait until every case is covered. The SRE Workbook stresses that moving 80 to 90% of requests to self-service is already a huge reduction in workload, the remaining cases still being handled by hand.
Reject the toil
Refusing is not ill will: it is an explicit trade-off, which the Workbook counts among the strategies in their own right. The question to ask the requester is what concretely happens if the task is not done this week. Often, the answer reveals no measurable consequence, which makes the refusal defensible.
When outright refusal is not possible, accumulate requests to handle them in batches rather than as they come, and use the grouping to spot patterns that recur: those are the ones to eliminate or automate first.
Use SLOs as a filter
With well-defined SLOs (Service Level Objectives, the quality thresholds the team commits to), you can ignore alerts that do not endanger the error budget, that is the unavailability margin the SLO allows. An alert that does not threaten the service objective has no reason to wake anyone up.
Take an availability SLO of 99.9% over 30 days: it allows about 43 minutes of unavailability (0.1% of 43,200 minutes). If the month has only used 4, a minor alert that represents 2 minutes of risk can wait until the next morning instead of triggering on-call at 3 a.m. SLOs are covered in the lesson SLO, SLI and error budgets.
Start with a human interface
For a complex problem, full of special cases, full automation from day one is a trap. The Workbook recommends a partially automated approach as an intermediate step, with a human "behind the curtain" handling the hard cases.
The progression is simple. First, a structured interface, a form that receives requests in a uniform way instead of free-text emails. Next, a human handles the requests, but on well-organised data. Finally, you automate progressively the most frequent cases, those that make up most of the volume, leaving the exceptions to the human.
Increase uniformity
At scale, every configuration variant adds a special case to handle by hand. The Workbook makes uniformity a strategy in its own right, summed up in DevOps culture by the phrase "cattle not pets": you no longer nurse a server individually, you rebuild it identically as soon as it drifts.
In practice, this means interchangeable servers, replaceable in minutes, a configuration described by Infrastructure as Code (versioned files that describe the expected state) so that all of them are configured exactly the same, and standard procedures: the same commands and the same tools everywhere. Drift from this reference state is then detected instead of being discovered during an incident.
Reduce the frequency
If full automation is too expensive in development time, reducing the frequency of the task can be enough to regain a comfortable margin.
Do you clean logs by hand every day? Configure a daily automatic rotation and check manually once a month. You have divided the toil by 30.
Simplify the process
As a last resort, if automation is impossible for technical or organisational reasons, at least simplify.
A 20-step runbook (a documented, step-by-step procedure an operator follows to solve a known problem, see the guide on designing a runbook, in French) can become an interactive script with three human checkpoints. You have not eliminated the toil, but you have cut it from 20 minutes to 3 minutes.
How do you automate without creating new risk?
An automation running with administrator rights can do more damage in a minute than a human in a week. The SRE Workbook therefore asks you to check the safety of every action before running it, and sets out three rules an operations script must follow from its first version.
- Validate inputs defensively, even those coming from upstream systems deemed reliable.
- Build in safeguards equivalent to the signals a human operator would have seen: a timeout on every command, a check of the system state before acting.
- Fall back to a human as soon as an unsafe condition is detected, rather than carrying on regardless.
Two principles complete these safeguards. Accept imperfection: an automation that covers the vast majority of cases is already a win, and waiting to handle every edge case blocks the project. Build reusable building blocks rather than monolithic scripts: a module that knows how to check disk space or restart a service cleanly will serve other automations.
Which mistakes should you avoid when reducing toil?
Failed toil reduction efforts almost always follow the same pattern: it is not automation that is missing, it is what surrounds it. A script with no documentation, no versioning or no metric creates a new dependency instead of removing one. Read the "Consequence" column first: it is what lets you recognise the situation you are already in, before applying the fix in the third column.
| What not to do | Consequence | Solution |
|---|---|---|
| Automating without documenting | Nobody knows how it works, you become indispensable (which feels flattering but traps you) | Document while automating |
| Ignoring toil | Gradual exhaustion of the team, demotivation, departures | Measure and make the problem visible |
| Automating halfway | Double work: maintaining the script AND doing the task by hand when it breaks | Go all the way or do not start |
| Unversioned scripts | Lost scripts, diverging versions, no way back | Git from day one, tests, CI/CD (continuous integration and delivery) |
| No metrics | Impossible to justify the time invested or show the gain | Measure the time before and after automation |
| Automating the critical last | The most important tasks remain human points of failure | Prioritise what has the most impact in case of error |
Examples of anti-toil projects
To make these principles concrete, here are three toil elimination projects with their quantified return on investment. The volumes are illustrative orders of magnitude, to be replaced with those from your own toil log.
Provisioning virtual machines
Initial situation: creating a VM takes 45 minutes. The user opens a ticket, an admin logs into the provider portal, creates the VM, configures the network, installs the monitoring agents, notifies the user. The team handles 50 requests a month.
Solution: a Terraform module defines the standard configuration. A CI/CD pipeline triggered by a self-service form provisions the VM in 5 minutes with no human intervention.
ROI calculation: before, 50 VMs x 45 minutes = 37.5 hours of toil a month. After, almost zero. Developing the Terraform module took 40 hours. Positive ROI after 5 weeks.
Secret rotation
Initial situation: every quarter, the security team requires secret rotation. An engineer spends 2 hours per service, for 15 services. Total: 30 hours of toil per quarter, within a constrained time window.
Solution: a secrets manager with automatic rotation. Applications fetch secrets dynamically. Rotation becomes invisible.
ROI calculation: 30 hours saved per quarter, plus the removal of the risk of forgetting, which could lead to costly security audits.
Cleaning up noisy alerts
Initial situation: the team receives 50 alerts a day. After investigation, 80% are false positives or alerts that resolve themselves. Each alert takes 5 minutes to investigate. Total: more than 4 hours of toil a day (50 × 5 minutes).
Solution: a systematic alert review. Removal of non-actionable alerts. Raising overly sensitive thresholds. Adding delays for transient problems. This approach matches the principles of good observability: a few actionable alerts are better than a continuous stream of noise.
ROI calculation: from 50 alerts to 10 relevant alerts a day. From more than 4 hours to 50 minutes of investigation time. And above all, a team that trusts its alerting system again.
Toil in the age of agentic AI
Since 2025, a new category of tools has promised to reduce toil other than by writing scripts: operational AI agents. Microsoft offers the Azure SRE Agent and AWS its DevOps Agent. These systems continuously watch production, analyse alerts with the available logs and metrics, and propose or execute remediation actions with execution guardrails.
This evolution does not replace the principles above, it moves them. An agent that restarts a service running out of memory automates a toil gesture, but if the memory leak is never fixed, toil comes back in another form: supervising the agent itself. The discipline stays the same: identify, measure, fix the root cause; only the executor changes.
Google Cloud's DORA 2025 report, the annual reference on software team performance described in more detail in our page on DORA metrics, confirms this point: AI amplifies existing practices rather than replacing them. Teams with mature DevOps foundations (automation, observability, internal platforms) turn AI gains into real performance. Teams without these foundations see AI amplify their existing disorder: more rework, more instability, with no net reduction in toil.
Building an anti-toil culture
Eliminating toil is not a one-off project, it is a permanent discipline. It requires a cultural change that goes beyond the technical toolbox alone.
Valuing automation as "real work"
In some organisations, writing an automation script is seen as time "stolen" from projects. It is a fundamental mistake. A script that saves 10 hours a month is worth more than a secondary feature. Measure and communicate these gains.
Budgeting time explicitly
Do not leave toil elimination to "quiet moments": they never come. Reserve 20% of the team's time for automation, or set up a monthly "Automation Friday" where everyone works on eliminating toil.
Documenting and celebrating gains
Make the savings visible. A post in the team channel: "Before: 2 h per request. After: 10 min in self-service. Monthly gain: 18 h. ROI: paid back in 2 months." It motivates and inspires other projects.
Resisting requests that create toil
Beware of innocent requests that create permanent toil. "Can you check X by hand every morning?" should trigger a question: "Can we automate this check?" Every toil commitment is a debt you will pay every day.
Where to start, and how to keep going?
Two lists serve as a roadmap. The first fits in a quarter for a team starting from scratch, and the order matters: the first three items produce the figures that will justify the time spent on the next ones. Without this initial measurement, a request for engineering time almost always runs into the argument "tickets first".
- List the team's recurring tasks
- Measure the time spent on toil (hours per week)
- Identify the three most expensive tasks
- Eliminate or automate a first critical task
- Document the automated process
- Version the scripts in Git
- Set up basic metrics
- Schedule a quarterly review
A mature organisation does not stand out by its number of scripts, but by the fact that toil reduction is budgeted and visible. The two items that make the difference are protected time, a percentage written into objectives rather than an intention, and automated rollbacks, which let the team automate risky tasks without gambling with production.
- Time budget dedicated to toil reduction (for example 20%)
- Tracking dashboard visible to everyone
- Self-service for common requests
- Toil indicators in team objectives
- Continuous user feedback
- Centralised, up-to-date documentation
- Automated rollback procedures
- Sharing gains with the rest of the organisation
Key points
- Toil is work that is manual, repetitive, automatable, tactical, with no lasting value, and that grows with the system. It is not just "boring", it is a precise six-point criterion, and it is their combination that counts.
- It is toxic for careers, morale, growth capacity and the technical quality of the organisation.
- The SRE 50% rule is an alarm ceiling, not a goal: Google measures about 33% internally, and the median observed in 2026 is around 34%.
- On a server fleet, toil mostly comes from recurring tickets, production interrupts, manual deployments and migrations that never end.
- Elimination follows a cycle: identify, measure with those who do the work, prioritise by ROI, then remove the cause before automating. Quick wins (high impact, low effort) come first.
- An automation protects itself: validated inputs, safeguards, fallback to a human, and a documented, versioned script.
- Operational AI agents (Azure SRE Agent, AWS DevOps Agent) move the execution of toil but do not spare you from fixing root causes.
- Culture matters as much as tools: value automation, budget time, celebrate gains, resist requests that create permanent toil.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: DORA metrics: measuring DevOps performance
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below cover the most frequent doubts about toil: its definition, the 50% rule, how to measure it and the place of AI agents.