Toil is manual, repetitive operational work that's tied to running a production service, that tends to scale linearly as the service grows, and that doesn't leave behind any lasting engineering value once it's done. The term was popularized by Google's Site Reliability Engineering practice, which defined it precisely to separate it from work that merely feels tedious. Toil isn't just "work nobody enjoys"; it's a specific category of operational labor with identifiable traits, and naming it precisely is what makes it possible to track, reduce, and eventually eliminate. An engineer can dislike a piece of strategic, high-value work just as much as a piece of toil, so the label has to rest on something more objective than how a task feels in the moment.
The reason toil matters enough to have its own term is that it quietly eats the capacity an engineering organization needs for the work that actually compounds. Every hour spent manually restarting a stuck job, manually provisioning a routine environment, or manually running the same investigation for the same alert is an hour not spent building the automation, tooling, or system improvements that would prevent that same work from recurring. Left unchecked, toil grows roughly in proportion to the number of services and the amount of traffic an organization runs, which means a team can be hiring and staffing up while somehow having less and less time available for actual engineering. This is the counterintuitive part that catches a lot of engineering leaders off guard: headcount growth and engineering output growth aren't the same curve, and toil is one of the main reasons they quietly diverge.
What distinguishes toil from other operational work is a specific, checkable set of characteristics: it's manual (a human has to do it by hand), repetitive (it happens the same way over and over), automatable (a machine could plausibly do it instead), tactical (it's reactive, interrupt-driven work rather than strategic effort), and it produces no enduring value (finishing it once doesn't reduce how often it needs to be done again). Work that's missing several of these traits, like a one-time migration or a complex incident investigation that teaches the team something new each time, usually isn't toil in the strict sense, even if it feels equally unpleasant in the moment.
By 2026, tracking and actively reducing toil has become a standard practice across mature platform and SRE teams, often formalized as a percentage-of-time budget (a common target, borrowed from Google's SRE practice, caps toil at around fifty percent of an engineer's time, with the rest protected for engineering project work). This has become more urgent, not less, as infrastructure has gotten more distributed and cloud-native, since more moving parts and more services generally mean more surface area for toil to quietly accumulate unless a team deliberately measures and pushes back against it. Organizations that don't track toil explicitly tend to discover it retroactively, usually when they notice that headcount has grown faster than the pace of actual feature or platform improvement. The rise of platform engineering as a discipline in its own right is, in part, a direct response to this: a dedicated team whose explicit job is building the self-service tooling and automation that keeps toil from swallowing every other engineering team's capacity.
This page covers what qualifies as toil and what doesn't, why it accumulates even in well-run organizations, how it overlaps with and differs from related ideas like technical debt and on-call burden, how it's measured and budgeted against, and what a team can practically do to reduce it without pretending it can be eliminated entirely. The durable idea behind toil is that not all operational work is equally valuable, and that distinguishing the automatable, repetitive kind from everything else is what lets a team protect the time it needs to actually get ahead of its own operational burden instead of merely keeping up with it. Getting the definition right isn't a semantic exercise, it's what determines whether a team spends its limited automation budget on the work that will actually pay it back.
The first and most literal trait of toil is that it's manual: a person has to actually sit down and do it, click the buttons, run the commands, or work through the steps by hand. This matters because manual work carries a cost that automated work doesn't, namely that it requires a specific person's attention at a specific moment, and that attention is a genuinely scarce and expensive resource compared to compute time, which is comparatively cheap and instantly available whenever it's needed.
The second trait is repetitiveness: toil happens the same way, or nearly the same way, over and over again. A one-time task, even a manual and tedious one, doesn't qualify as toil under the strict definition, because a single occurrence doesn't create the compounding drain that repeated occurrences do. This is part of why the definition matters practically: it tells a team where automation investment actually pays off, since automating something that happens once provides little future benefit, while automating something that happens fifty times a month pays for itself quickly.
The third and fourth traits, automatable and tactical, work together to identify what's worth fixing and what's just inherently reactive. Automatable means a machine could plausibly do the task with the same or better reliability than a human, which rules out work that genuinely requires human judgment, like deciding how to communicate a sensitive incident to customers. Tactical means the work is interrupt-driven and reactive, responding to something that already happened, rather than planned, proactive engineering effort; toil is almost always the former, since planned engineering work, even repetitive planned work, tends to get scheduled and improved over time in a way toil, by its interrupt-driven nature, resists.
The fifth trait, no enduring value, is arguably the one that often surprises people the most when they first encounter the formal definition, because it draws a sharp, useful line between toil and merely difficult engineering work that happens to feel similarly draining in the moment. Debugging a genuinely new, previously unseen production issue is hard and often unpleasant, but it usually produces lasting value: a new runbook, a new alert, a fix that prevents recurrence, or at minimum, new understanding the team didn't have before. Toil, by contrast, leaves the system exactly where it was before the work was done; restarting a service that crashes the same way every week doesn't make the service any less likely to crash the same way next week, which is precisely why it qualifies as toil and a genuine root-cause fix for that same crash would not.
Toil tends to accumulate because the incentives around fixing it and the incentives around just doing it are misaligned in ordinary, unremarkable ways. Doing the manual task in front of you right now, to make an alert stop firing or a customer stop complaining, has an obvious and immediate payoff. Investing the time to actually automate that task away has a payoff too, but it's delayed, uncertain in exact size, and competes directly with the next sprint's feature commitments, which makes it easy to defer indefinitely even when everyone involved would agree, in the abstract, that fixing the root cause is the better long-term investment. This is a classic short-term-versus-long-term tradeoff, and short-term almost always wins by default unless something deliberately tips the scale back the other way.
Growth is the second major driver, and it's often the most mechanical one. A manual process that took ten minutes a month when a company had five services and ran fine for years can quietly turn into a serious drain once that same company has fifty services, because the same fundamentally manual process now happens fifty times as often, or in fifty different variations that all need slightly different handling. Nobody made a bad decision at any single point in this story, the process just never got automated, and the linear scaling of a manual process against a growing system size is what turns a minor inconvenience into a genuine capacity crisis over a few years.
Tooling gaps are a third driver, and they're often invisible until someone actually goes looking for them. A team might not have self-service provisioning, a working runbook automation system, or reliable auto-remediation for known failure modes, not because nobody thought of building those things, but because building them competes for the same engineering time that toil itself is consuming, creating a self-reinforcing trap where the busier a team gets doing manual work, the less time it has to build the automation that would free it from doing that manual work in the first place.
Organizational blind spots round out the picture, and they're arguably the hardest to fix because nobody is deliberately hiding anything. Toil is easy to undercount because it tends to get absorbed silently into "operational overhead" or "keeping the lights on" categories that don't get scrutinized the way project work does, and because individual engineers often don't flag their own toil as a problem, either because they've normalized it as just part of the job or because complaining about repetitive work can feel like complaining about doing their job at all. Without a deliberate measurement effort, toil often stays invisible precisely because it's distributed across many small, individually unremarkable interruptions rather than showing up as one obvious, glaring problem.
Toil is often confused with technical debt, but the two describe different problems. Technical debt is a property of the system itself, shortcuts taken in design or implementation that make future changes harder or riskier. Toil is a property of the operational work required to keep the system running day to day. The two are related, since bad technical debt often generates a steady stream of manual firefighting, but fixing technical debt and fixing toil are different projects with different fixes; paying down debt might mean rewriting a fragile subsystem, while reducing toil might mean building a self-service tool or an auto-remediation script for a symptom the debt keeps producing.
Toil also gets conflated with "on-call burden" generally, but on-call includes plenty of work that isn't toil, including genuinely novel incidents, judgment calls about customer communication during an outage, and the kind of investigation that produces new understanding of a system's failure modes. Reducing toil can meaningfully lighten on-call load, since a lot of what makes on-call miserable is exactly the repetitive, already-solved-a-hundred-times alert, but it doesn't eliminate on-call as a concept, because someone still needs to be reachable for the genuinely new problems that automation, by definition, hasn't been built to handle yet.
It's also worth distinguishing toil from work that's simply low-status or unglamorous but still produces real value, like writing documentation, doing careful code review, or maintaining a test suite. These tasks can feel similarly unrewarding in the moment, and teams sometimes lump them in with toil when complaining about their workload, but none of them meet the strict definition, since they generally aren't purely manual-repetitive-automatable-tactical-with-no-lasting-value; they leave the system, or the team's shared understanding, meaningfully better off afterward.
Getting this distinction right matters because the fixes are different. Toil gets fixed by automation and self-service. Technical debt gets fixed by deliberate engineering investment in the system's design. On-call burden gets addressed partly by reducing toil and partly by better incident response practices and clearer escalation paths. Treating all three as the same problem, and reaching for automation as the answer to all of them, means solving the toil piece while leaving the debt and the on-call structure exactly as they were.
The starting point for measuring toil is simply tracking how engineers actually spend their time, which sounds simple and is usually harder than expected, because most engineering time-tracking tools weren't built with this specific categorization in mind. Some teams use lightweight tagging on tickets or interrupts (labeling each piece of work as toil, project work, or something else) while others rely on periodic time-use surveys, asking engineers to estimate what fraction of the last week or month went to manual, repetitive operational work versus planned engineering effort. Neither method is perfectly precise, but both are far better than not measuring at all, since even a rough number turns a vague feeling of being overwhelmed into a concrete, trackable metric.
Google's SRE practice popularized the specific target of capping toil at around fifty percent of an SRE's time, with the explicit understanding that any more than that starts crowding out the engineering project work needed to actually reduce toil over time, creating exactly the self-reinforcing trap described earlier. This particular number isn't a universal law, and different organizations reasonably land on different thresholds depending on how mature their automation already is, but the underlying principle, that toil needs an explicit ceiling rather than being allowed to expand to fill all available time, holds regardless of the specific percentage chosen.
Turning the raw measurement into an actual working budget requires giving it real teeth, which usually means treating toil reduction as a genuine, prioritized line item in ordinary planning cycles, not an aspiration that quietly gets deprioritized the moment a launch deadline gets tight. Teams that measure toil but never act on the number tend to find that the measurement alone doesn't reduce anything; it just produces an accurate, well-documented account of a problem that keeps getting worse. The measurement's value comes entirely from what a team does with it afterward, specifically whether crossing the toil ceiling triggers a real conversation about priorities rather than being quietly absorbed and forgotten.
Trend lines matter more than any single snapshot taken in isolation. A team at forty percent toil that's been climbing steadily for six months is in a fundamentally different, more urgent situation than a team that's been stable at forty percent for two years, even though the single-point measurement, viewed alone, looks identical in both cases. Tracking toil over time, and specifically watching whether automation investments are actually bending that trend downward, is what turns a static metric into something a team can actually manage against, rather than a number that gets reported once and never revisited.
The first practical step is inventorying and ranking existing toil by frequency and cost, rather than trying to tackle everything at once or picking whatever feels most urgent in the moment. A short list of the tasks that happen most often, take the most cumulative time, or generate the most interruptions during off-hours tends to reveal a small number of genuinely high-leverage automation targets, and fixing those first produces the most visible, most immediate reduction in overall toil, building momentum and credibility for further investment down the line.
Automating the underlying cause, not just the symptom, is what actually produces lasting reduction rather than a temporary reprieve. A script that automates the manual steps of restarting a flaky service is a real improvement over doing those same steps by hand, but it's still a smaller version of toil rather than an elimination of it, since something still has to notice the failure and trigger the script. Genuinely eliminating that toil means fixing whatever makes the service flaky in the first place, so the restart, automated or not, becomes unnecessary altogether.
Self-service tooling is one of the most reliable long-term levers against toil, because a large share of operational toil is actually just ordinary requests that a human currently has to fulfill by hand: provisioning an environment, resetting a credential, scaling a workload that behaves in a well-understood, predictable way. Every one of these that gets converted into something a requester can do themselves, through a portal, a CLI, or an automated workflow, removes a recurring source of interruption from the team that used to fulfill it manually, which is exactly why platform teams building genuine developer self-service tend to see toil drop as a direct, measurable side effect rather than a coincidence.
Protecting the time to actually do the automation work is the step that most often gets skipped, and it's usually the real reason toil-reduction efforts quietly stall out even when everyone in the room genuinely agrees on the plan. If engineers are expected to squeeze automation projects into whatever time is left over after handling the day's interrupts, and that time is exactly what toil is consuming, the automation project simply never gets the sustained attention it needs to finish. Treating toil-reduction work as a scheduled, protected commitment, the same way a feature launch would be scheduled and protected, is what actually gets it done instead of leaving it perpetually one sprint away from starting.
Toil is manual, repetitive operational work tied to running a production service that tends to scale with the size and traffic of that service, and that doesn't produce any lasting engineering value once it's completed, a definition popularized and formalized by Google's Site Reliability Engineering practice in its influential engineering literature.
Toil has a specific set of traits: it must be manual, repetitive, automatable, tactical or reactive, and devoid of enduring value. Difficult work that produces lasting value, such as a novel incident investigation that teaches the team something new or leads to a fix, doesn't count as toil even though it can feel just as draining.
No, not at all. On-call work that involves genuinely new problems, produces new understanding, or leads to a permanent fix generally isn't toil. Toil specifically describes the repetitive, already-understood tasks that keep recurring in the same form without contributing anything new each time they happen.
There's no single universal number here, but Google's SRE practice popularized capping toil at around fifty percent of an engineer's time, leaving the remaining half protected for engineering project work. Different organizations may reasonably set a different threshold depending on how mature their existing automation already is.
Not permanently, no. Toil can be substantially reduced through automation, self-service tooling, and root-cause fixes, but new sources of toil tend to emerge as systems, services, and traffic patterns continue to change over time, so toil reduction is best treated as an ongoing practice rather than a one-time project with a clear finish line.
Manual processes that were perfectly manageable at a small scale often become disproportionately expensive as the number of services, requests, or customers grows, because the same manual steps now have to happen far more often than before. Nobody necessarily made a bad decision; the process simply never got automated before growth made its cost much more visible.
A large share of ordinary operational toil consists of requests, like provisioning an environment or resetting a credential, that a human currently has to fulfill manually. Converting those requests into genuine self-service actions removes a recurring source of manual, repetitive work from the team that used to handle them by hand, directly reducing toil as a side effect.
Not necessarily, and this is a common misstep. Automating the steps of a recurring task, such as scripting a service restart, can still leave a smaller version of the toil in place if the underlying cause of the recurring problem isn't fixed, since something still has to detect the failure and trigger the automation each time it happens.
A practical starting point is either tagging tickets and interrupts as toil versus project work, or running periodic time-use surveys asking engineers to estimate what share of their recent time went to manual, repetitive operational tasks. Neither method is perfectly precise, but either one turns a vague sense of being overloaded into a concrete, trackable number a team can actually plan and act on.
