In SRE, what makes operational work count as "toil", and name two kinds of manual work that are not toil?

## Why the word needs a definition at all Every operations team has work it resents, and every team would like that work automated. "Toil" is SRE's attempt to make that argument fundable rather than emotional. If toil is precisely defined and measured, a team can say "41% of our engineering time went to toil last quarter, here are the three sources, here is what we intend to spend to remove them" — and a manager can act on it. If toil just means "work we don't enjoy", the number is unfalsifiable and nobody will fund anything on the strength of it. ## The criteria Google's Site Reliability Engineering book gives six tests. Work is toil when it is: - **Manual** — a human has to touch it. Time spent hand-running a script counts; the script running itself does not. - **Repetitive** — you have done it before and you will do it again. First time is investigation; the twentieth time is toil. - **Automatable** — a machine could plausibly do it. If the task requires judgement no one has yet been able to encode, it is not toil, it is engineering. This is the criterion that keeps incident diagnosis out of the bucket. - **Tactical** — it is reactive and interrupt-driven rather than strategy-driven. A page you answer at 3am is tactical; the capacity plan you write on Tuesday is not. - **Devoid of enduring value** — when you are done, the service is in the same state it was in before. You restarted the stuck worker; nothing about tomorrow got better. - **Growing at least linearly with service size** — the cost of the task rises as the estate grows. This is what makes toil an existential problem rather than an annoyance: work that scales with the service eventually consumes the whole team. In practice you rarely need all six to make a call, but the two that do the most classifying work are *automatable* and *no enduring value*. If a task leaves something permanently better, or if nobody knows how a machine would do it, it is not toil. ## What is not toil Three categories get misfiled constantly. **Overhead.** Meetings, performance reviews, hiring loops, expense reports, planning. These are manual, repetitive and arguably valueless, but they are not operational work on your service, they do not scale with it, and your team cannot automate them away. They belong in a separate line of the time budget. Folding them into the toil number inflates it and makes the whole measurement easy to dismiss. **Project and engineering work.** A migration, a schema change, a new deployment pipeline. Manual, sometimes deeply tedious, but each one leaves the system permanently different. Doing it once is investment, not toil. If you find yourself doing the "one-off" migration for the eleventh time, it has become toil and you should say so. **Genuine incident response.** The novel outage where you don't know what is broken is the opposite of toil: it is not repetitive, not automatable, and the understanding it produces is enduring value. What *is* toil is the incident you have seen fifteen times, where you follow the same steps to the same resolution. ## Toil is not bad work, and it is not zero Two corollaries candidates often miss. First, toil is legitimate, necessary work. Someone genuinely does have to restart the worker. Calling it toil is not calling it beneath anyone, and an SRE who refuses to do operational work has misread the idea entirely. The claim is only that its *share* of the team's time has to be bounded, because a team at 100% toil has no capacity left to make next quarter cheaper than this one. Second, the target is not zero. Google's published guidance is a ceiling of roughly 50% of an SRE's time, precisely because some toil is the price of running a real service and because keeping engineers in touch with production has value. A team reporting 0% toil is either not operating anything or not measuring. ## Applying it The useful exercise in an interview is classification. Given a queue — quarterly certificate renewals, a customer's data-export request, a flaky test rerun, a capacity review, a manual production release, a novel latency investigation — say which are toil and why, and the honest answer will not be "all of them". Certificate renewal and the manual release are textbook toil: repetitive, automatable, leaving nothing behind, and each new service adds another one. The capacity review and the latency investigation are engineering. The export request is toil only if it keeps coming; if it is the first, it is a signal you may need a self-service feature. The classification is the whole point: it converts a vague complaint into a prioritised list of things worth building.