“Toil” is often used as a vague synonym for “tedious work” or “repetitive task,” when the term, as defined by the Google SRE Book, actually meets five precise criteria: without all five present together, a repetitive task isn’t necessarily toil, a distinction that concretely changes what a team decides to automate first.

The five criteria that define toil

A task is only toil if it’s simultaneously: manual (requires direct human intervention), repetitive (recurs regularly, not a one-time occurrence), automatable (a technical solution exists or could exist), tactical (reactive, in response to an event, rather than strategically planned), and devoid of enduring value (the service isn’t in a better state once the task is done than before it started).

Manual + Repetitive + Automatable + Tactical + No enduring value
= Toil

Manually restarting a service that crashes regularly for the same known reason checks all five boxes: manual, repetitive, automatable (an auto-restart script could exist), tactical (a reaction to a crash), and devoid of enduring value (the service returns to exactly its previous state, the bug is still there).

What isn’t toil, despite appearances

Writing a design document, even repeated for every new project, isn’t toil: the task produces enduring value (a documented architectural decision that structures future work), even though it’s manual and recurring. A one-off manual intervention for a single migration isn’t toil either, for lack of repetition. The enduring-value criterion and the repetition criterion rule out a large share of tasks wrongly labeled toil out of sheer fatigue.

Why this precision matters for prioritizing automation

A team that treats every repetitive task as toil risks investing disproportionate engineering time automating a rare or low-impact task, rather than targeting first the tasks that genuinely check all five criteria, usually the ones consuming the most on-call time without ever fixing the underlying problem. The error budget helps decide when to invest in reliability rather than new features; the five toil criteria help decide, once that investment is decided, which task to automate first.

Takeaway

Toil meets five precise criteria (manual, repetitive, automatable, tactical, devoid of enduring value), a far narrower definition than “tedious work” in general. A repetitive task that generates enduring value (a design document, an architectural decision) isn’t toil, even repeated on every project. This precision matters concretely for prioritizing automation: targeting what genuinely checks all five criteria avoids investing disproportionate engineering time on a rare task instead of the one actually consuming on-call time without ever fixing the underlying problem — the same honest reconstruction of root causes already described for a blameless postmortem, which often reveals the real toil behind an incident rather than a superficial cause.