Reducing Toil
Module 3 of the SRE Foundation blueprint tests one narrow, precise skill: given a paragraph describing a task an engineer does, can you say whether it legally counts as toil — and defend the answer against all six properties, not just the one that feels obviously true? This page gives you the exam-ready version of that test: the formal definition compressed into six pass/fail gates, the neighboring categories the exam likes to disguise toil as (or disguise as toil), and a set of worked classification calls in the exact style the real questions use. For the full origin story of the definition, the 50% cap, and the automation ladder that gets a toil source off your plate, see toil and automation — this page assumes that content and drills the judgment call on top of it.
Imagine a game show where a task walks onstage and the host asks the audience "Toil, or not toil?" Before anyone buzzes in, they have to run it through six yes/no questions: did a person do it by hand, have they done this exact thing before, could a machine do it instead, did it interrupt something planned, did it leave anything better than before, and does doing more of the same thing get needed as the show gets bigger? Answer "yes" to all six and the buzzer lights up TOIL. Answer "no" to even one, and it doesn't matter how annoying or repetitive the task felt — it's disqualified, and it goes back to being called ordinary work instead. The exam is that buzzer, and this page is the six questions.
What Module 3 actually tests
☺ Like you're 10: The exam doesn't ask you to define toil from memory — it hands you a mini-story about an engineer and asks whether that specific story counts.
The SRE Foundation blueprint arranges its eight modules to build outward from the practice's core mechanisms: Module 1 covers SRE principles and practices in general, Module 2 covers SLOs and error budgets — the number that decides how much unreliability is acceptable — and Module 3 covers toil: the operational cost of keeping a service inside that number by hand instead of by design. The pattern the exam leans on across this module is consistent: rather than asking you to recite the definition, it describes a concrete scenario — an engineer doing something, on some cadence, for some reason — and asks you to classify it. Sometimes it's a single scenario with a yes/no answer; sometimes it's several short scenarios and you have to pick which ones qualify. Either way, the skill being tested isn't recall, it's application: can you run an unfamiliar situation through the same six-property test every time, instead of pattern-matching on "this sounds tedious, so it must be toil."
DevOps Institute doesn't publish an official per-module weighting for the SRE Foundation exam the way some vendor certifications do — there's no confirmed "Module 3 is worth 12% of the exam" figure to study to. Treat all eight modules as roughly equally likely to show up across the exam's 40 questions, and verify the current syllabus and any weighting on the DevOps Institute's own page before you calibrate your study time around a specific percentage.
The six-gate test
☺ Like you're 10: All six have to be true at once — this is the single detail that decides most exam questions in this module.
A task is toil only if it clears every one of the following. The exam's favorite trick is to write a scenario that satisfies five of the six convincingly and quietly fails the sixth — so treat this as a checklist to run in full, not a vibe to pattern-match.
| # | Property | What the exam is actually asking |
|---|---|---|
| 1 | Manual | Is a person directly executing the steps, rather than supervising something that already runs itself? |
| 2 | Repetitive | Has this exact task happened before, and will it happen again — or is the scenario describing something novel? |
| 3 | Automatable | Could a machine do it as well as a person, with no genuine judgment call required — or does the scenario hinge on expertise a script can't replicate? |
| 4 | Tactical | Is it interrupt-driven and reactive — triggered by an alert, a ticket, a threshold — rather than something chosen as part of a plan? |
| 5 | No enduring value | Once it's done, is the system in exactly the same state it would've been in if the problem had never happened — or did the task leave behind a fix, a tool, or knowledge that pays off later? |
| 6 | O(n) with growth | Does the volume of this work scale linearly with fleet size, customer count, or traffic — or is it a fixed, one-time, or sub-linear cost? |
Notice the shape of that last column: three of the six (automatable, tactical, no enduring value) are the ones exam scenarios most often use to disqualify a task that otherwise looks like toil. A task can be manual and repetitive and still fail the test entirely on one of those three.
Toil is not a synonym for "unpleasant" — the three-bucket model
☺ Like you're 10: Everything an engineer does sorts into one of three drawers — building something new, doing the same fix-it chore again, or paperwork that isn't really about the service at all — and only the middle drawer is toil.
The most common exam trap in this module isn't a missing property — it's forgetting that toil has to be distinguished from two other categories, not one. The Site Reliability Engineering book's own accounting splits an SRE's time into three buckets, and the exam expects you to sort a scenario into the right one:
- Engineering project work. Writing code, designing a system, debugging a novel failure, building a dashboard. This is the opposite of toil on purpose — it has enduring value (the thing you built keeps paying off) and it doesn't scale linearly with the service, since a well-built tool serves 10x the fleet without 10x the effort.
- Toil. Everything that clears all six gates above.
- Overhead. Administrative work that isn't tied to running a live production service at all — team meetings, filling out a headcount-planning spreadsheet, HR training, interviewing candidates, expense reports. Overhead can be just as recurring and just as tedious as toil, and it's still not toil, because it fails the definition at a more basic level: it was never operational work on the service in the first place.
Toil and overhead are cousins that get confused constantly, and the exam knows it. Both can feel like a drain on "real" engineering time. The test that separates them isn't the six-gate checklist at all — it's one prior question: is this work about operating the production service, or not? If the task wouldn't exist without the service running (restarting a process, provisioning a resource, rotating a cert), it's a toil candidate — run the six gates. If it would exist regardless of whether the service is even in production (a status meeting, a performance review, a training course), it's overhead, full stop, no gate-checking required.
Four traps that account for most of the wrong answers in this module: (1) a task can be manual and repetitive and still not be toil — check automatable, tactical, and no-enduring-value before you commit to an answer, since those three disqualify more scenarios than "manual" or "repetitive" ever do. (2) A genuinely novel task is never toil, no matter how tedious it was to do — "first time we've ever seen this" fails repetitive immediately. (3) A task that requires real judgment — a security review, an architecture sign-off, a deploy approval that actually reads the diff — fails automatable even if it happens on every single release; don't let "manual + high frequency" override the judgment-call test. (4) Recurring administrative work (meetings, planning spreadsheets, training) is overhead, not toil — it never even reaches the six-gate test because it isn't operational work on the service.
Worked examples: run the checklist
☺ Like you're 10: Here are five mini exam questions, answered out loud — watch which single gate decides each one.
These follow the exact shape the real exam uses — a short scenario, then a call. Read each one and try to name the deciding property before you check the "why" column.
| Scenario | Verdict | Why |
|---|---|---|
| An on-call engineer restarts a hung payment-worker pod three or four times a week; the underlying memory leak has never been root-caused. | Toil | All six hold: hands-on, recurs weekly, a process supervisor could do the restart, it's purely a reaction to a page, the pod ends up exactly where it was before it hung, and restart volume grows with worker count. |
| An SRE spends two days chasing a data-corruption bug the team has never seen before, then ships a schema-validation fix that prevents it recurring. | Not toil | Fails repetitive (never seen before) and no-enduring-value (the fix leaves the system better than it started) — this is engineering project work, even though it was unplanned and stressful. |
Every time a new microservice team onboards, a platform engineer hand-runs the same seven kubectl/gcloud commands to create its namespace, IAM role, and CI pipeline. | Toil | Manual, recurs per onboarding, fully scriptable into an IaC template with zero judgment required, triggered reactively by each onboarding request rather than planned, restores nothing beyond baseline setup, and scales linearly with team count. |
| A senior engineer reads the diff and manually approves every production deploy before it merges. | Usually not toil | Manual and repetitive, yes — but reading a diff for risk is exactly the judgment call a script can't safely replace, so it fails automatable. (If the "review" turns out to be a rubber-stamp click on anything that passed CI, the judgment is illusory and the exam may expect toil instead — read for whether real judgment is actually being exercised.) |
| An engineer spends 45 minutes each week updating the on-call handoff spreadsheet and attending the reliability status meeting. | Overhead, not toil | Administrative work that isn't operating the production service — it never reaches the six-gate test at all, because the prior "is this about running the service" question already sorts it into the third bucket. |
Where this connects in the blueprint
☺ Like you're 10: Classifying toil is only step one — the next question is always "so what do we do about it," and that's a different lesson.
This page deliberately stops at classification. Once you can call a scenario toil with confidence, the next layer — how much toil is acceptable and what you do when it's over the line — is Google's 50% cap, and the concrete ladder for walking a toil source from fully manual to fully autonomic, both covered in full in toil and automation. That page also has the worked automation-ladder examples (restarting a service, provisioning a customer, rotating a certificate) that this page's classification skill feeds directly into — classify first, then automate. Coming right after this module, monitoring & service level indicators covers the telemetry that tells you a toil source is even happening, and SRE tools & automation covers the concrete tooling — schedulers, IaC, ChatOps — that climbs the automation ladder in practice. Looking backward, SLOs & error budgets is where the number that toil-reduction work ultimately protects gets defined in the first place.
Pull up Drill — Audit the Toil and run five real tasks from your own on-call rotation (or the drill's sample list) through the six-gate test above. For each one, write a one-line verdict citing the specific gate that decided it — not just "toil" or "not toil," but which of the six properties (or the overhead pre-check) made the call. That one-line habit is precisely what the exam is scoring.
Foxy: Quiz me. I patch a flaky DNS config by hand every time a new region comes online. Toil?
Benny the Beaver: Run the six gates. Manual — yes. Repetitive — yes, happens every region launch. Automatable — almost certainly, it's the same values every time. Tactical — hm, is a planned region launch really "interrupt-driven"?
Timmy the Turtle: It's reactive to the launch event even if the launch itself was scheduled — the task itself wasn't chosen as engineering work, it's a chore riding along. I'd still call it tactical.
Sol the Sloth: And no enduring value — the DNS config is right back where every other region's config already is, nothing new was learned. And it scales with region count. Six for six. Toil.
Remy the Rabbit: Toil! Automate it, next question!
Professor Owl: Slow down, Remy — Sol just showed you the work. On the exam, the deciding gate is worth more than the fast answer.
1. Name all six properties a task must have to count as toil. 2. A task is manual, repetitive, and happens on every release — but requires a real security judgment call each time. Is it toil? Which gate decides it? 3. What's the difference between toil and overhead, and what's the one prior question that sorts a task into the overhead bucket before you'd even run the six gates? 4. Where should you go for the 50% cap and the automation ladder that follows a toil classification?
Check your answers
- Manual, repetitive, automatable, tactical, no enduring value, and O(n) — scales linearly — with service growth.
- No — it's not toil. It fails automatable: a genuine judgment call is exactly the kind of step a machine can't safely replace, even though the task is manual, repetitive, and frequent.
- Overhead is administrative work not tied to operating the production service at all (meetings, headcount planning, HR training); toil is operational work on the service itself that clears all six gates. The prior question is: "is this work about running the service, or not?" — if not, it's overhead and the six-gate test never even applies.
- Toil and automation — it covers the 50% cap Google enforces as policy and the five-rung automation ladder that takes a classified toil source from fully manual to self-service/autonomic.