“Toil” sounds like a general complaint about tedious work, but in Google’s Site Reliability Engineering practice it’s a precisely defined term with specific criteria — and that precision is exactly what makes it useful as an engineering concept rather than just a mood.

The specific definition

Google’s SRE book devotes a full chapter to eliminating toil, and it defines toil narrowly, not as “any operational work” but as work with a specific combination of characteristics: it is manual, repetitive, automatable, tactical (interrupt-driven rather than strategic), provides no enduring value (the system is no better off after it’s done than before), and scales linearly with the size of the service — meaning it grows in direct proportion to system size or traffic, rather than the effort needed staying roughly constant as the system grows.

That last property is a key part of why toil specifically matters: work that scales linearly with growth will, left unaddressed, eventually consume all available engineering time as a system grows, no matter how much staff is added, since the work grows at the same rate as everything else.

What counts, and what doesn’t

Restarting a service manually every time a known, understood failure occurs is toil — manual, repetitive, automatable, and it leaves the underlying cause of the failure exactly as fixable-or-not as it was before. Responding to a genuinely novel incident, discussed in How On-Call and Incident Response Actually Work, and writing a postmortem that identifies a systemic fix is not toil, even though it’s also operational and reactive — it produces lasting value, in the form of a system that’s actually more resilient afterward. The distinction isn’t “operational versus non-operational” or “manual versus automated” alone — it’s whether the work leaves the system meaningfully better off, and whether it’s the kind of repetitive task that could, in principle, be automated away.

Why this precision is the whole point

A vague sense that “we spend too much time on busywork” is hard to act on — it’s not measurable, and it’s easy to dismiss as a complaint about ordinary operational reality rather than a genuine, addressable engineering problem. Defining toil against specific criteria turns it into something that can actually be tracked (what fraction of the team’s time is going to toil, as strictly defined) and prioritized against other work, the same way SLOs and error budgets turn “be reliable” into something measurable and actionable rather than an abstract goal.

Toil and automation investment

Because toil scales linearly with system size and is by definition automatable, it’s specifically the category of work that pays back automation investment most reliably: a fixed engineering cost to automate a toil source removes work that would otherwise keep growing indefinitely. This is one of the clearer, more concrete justifications for investing in GitOps and broader automation, beyond a general sense that “automation is good” — toil elimination gives a specific category of recurring manual work to target first, rather than automating indiscriminately.

Why measuring toil also protects against burnout

Google’s SRE practice frames excessive toil as a genuine organizational risk, not just an efficiency problem: a team spending most of its time on toil has correspondingly less time for the engineering work that actually improves the system, and doing repetitive, low-value work indefinitely is a well-documented driver of burnout and attrition. Tracking toil as a specific, named category gives a team a legitimate, concrete basis for pushing back on an unsustainable operational load, rather than relying on a general sense that things feel overwhelming.

Key takeaway

Toil, in Google’s SRE practice, is a precisely defined category of operational work — manual, repetitive, automatable, and providing no lasting value, scaling linearly with system growth — not simply a synonym for tedious work in general. Measuring it against those specific criteria is what turns a vague complaint about busywork into a concrete, trackable target for automation investment, with real stakes for both system reliability and team sustainability.

This article explains a general SRE concept; specific application depends on your team’s operational reality. See our disclaimer.