5 exercises — Practice vocabulary for toil identification and reduction: defining toil, quantifying time saved, the 50% toil cap, and making the case for automation.
0 / 10 completed
1 / 10
At a team retrospective, an SRE says: "This task is manual and repetitive — it qualifies as toil." A developer asks what makes something "toil" in the SRE sense, rather than just "a boring task." Which definition is most accurate?
Google's SRE definition of toil has six specific characteristics — all six together define toil, not just one.
The six characteristics from Google's SRE book:
1. Manual — a human performs the steps
2. Repetitive — done again and again, not a one-time task
3. Automatable — a machine could do it with sufficient engineering
4. Tactical — reactive/interrupt-driven, not proactive
5. Scales with service growth — more traffic/users = more of this work
6. No enduring value — completing it leaves the service in exactly the same state
A post-mortem analysis is manual and time-consuming, but it is not toil — it produces enduring value (improved reliability, documented learnings). Toil is specifically work that a machine could replace.
Key vocabulary:
• toil — manual, repetitive, automatable operational work that scales with service size
• enduring value — lasting improvement to the system or team capability
• tactical work — reactive, interrupt-driven work; opposite of strategic engineering
• toil budget — the maximum acceptable percentage of an SRE's time spent on toil (typically <50%)
2 / 10
In a quarterly planning meeting, an SRE says: "Automating this saves approximately 4 hours per week across the team." A manager asks how this estimate was calculated. Which approach is correct SRE practice for toil quantification?
Quantifying toil with specific numbers (time per instance × frequency × affected engineers) is essential for making the case for automation investment — it turns "this is annoying" into "this costs us 200 hours per year."
The formula: Time per instance × frequency × number of engineers affected = total toil cost
Annual view: 4 hours/week × 52 weeks = 208 engineer-hours per year. At a fully-loaded cost of $150/hour, this is $31,200/year. If automation takes 40 hours to build and maintain, the ROI is clear within 2 months.
Common toil tracking approaches:
• Time-box a week and log every manual task
• Analyse on-call shift handoff notes for recurring patterns
• Count unique alert types and their manual response time
Key vocabulary:
• toil quantification — measuring toil in concrete time units (hours per week/month)
• automation ROI — the return on investment from automating a toil task (time saved vs. time to build)
• toil tracking — systematically recording time spent on manual operational tasks
• engineer-hours — a unit measuring human time cost of work
3 / 10
An SRE presents to leadership: "We propose automating the certificate renewal process. Currently this task is manual and repetitive — it requires an engineer to log in, run three commands, and verify output every 90 days per certificate, across 47 certificates." Which phrase from this statement most precisely identifies it as toil?
"Manual and repetitive — run three commands and verify output" is the toil identification language — it names the human action, confirms the fixed sequence, and implies automability.
When writing a toil identification statement for a proposal, the effective structure is:
1. Name the task: "certificate renewal"
2. State it is manual: "requires an engineer to log in"
3. Describe the repetitive sequence: "run three commands and verify output"
4. Give frequency and scale: "every 90 days, 47 certificates"
5. Quantify the cost: 47 × (15 min per renewal) = 11.75 hours every 90 days = ~47 hours/year
The 47-certificate scale does amplify the cost but is not what defines toil — even one certificate renewed manually every 90 days is toil if a human must do it each time.
Key vocabulary:
• toil identification language — phrases like "manual and repetitive," "same steps each time," "requires human intervention"
• automatable sequence — a fixed series of steps that can be replaced by a script or system
• scale amplifier — the multiplier that makes toil cost higher (more certificates, more services, more engineers)
• toil proposal — a document making the case for automation, including quantified toil cost and automation effort
4 / 10
An SRE team lead says in a planning session: "We're spending 60% of our time on toil. We need to bring that below 50%." A new team member asks why 50% is the target. Which explanation is correct?
The 50% toil cap is a structural safeguard: if an SRE team spends more than half its time on manual operational work, it cannot improve the systems that generate that work — creating a toil trap.
The toil trap dynamic: high toil → less time for automation → systems grow without reliability improvements → more toil. The cap forces the organisation to invest in automation before the team is completely consumed by operations.
In practice, teams track toil percentage via:
• On-call shift logs
• Time-boxed toil audits
• Categorisation of tickets as toil vs. project work
If toil exceeds 50%, the escalation path is: document the excess, raise it in planning, and request either additional engineering headcount or reduction in service scope until automation catches up.
Key vocabulary:
• toil ratio — percentage of SRE time spent on toil vs. engineering/project work
• toil cap — the maximum acceptable toil ratio (50% in the Google SRE model)
• toil trap — a feedback loop where high toil prevents automation investment, causing more toil
• toil escalation — formally raising excess toil to management as a capacity and risk issue
5 / 10
After automating a deployment verification task, an SRE reports: "Automating this saves 6 hours per week. Over the quarter, that is 78 hours of engineering capacity reclaimed for project work." Which term best describes what the team has done, and why does it matter?
Toil reduction is the SRE practice of systematically identifying and eliminating manual operational work through automation — the goal is to convert reactive human time into proactive engineering capacity.
The "78 hours reclaimed" framing is important: it connects toil reduction to a concrete business outcome. 78 hours is roughly 2 engineer-weeks per quarter — time that can now be spent on:
• Improving reliability (reducing toil that remains)
• Building internal tooling
• Proactive capacity planning
• Improving observability and alerting
Toil reduction is different from incident prevention (which reduces how often things break) and refactoring (which improves code quality). It specifically targets the operational overhead of running a service at scale.
Key vocabulary:
• toil reduction — the process of identifying and eliminating manual operational work through automation
• engineering capacity reclaimed — the productive time freed up by automation; used for strategic work
• operational overhead — the ongoing human effort required to keep a service running at scale
• strategic work — engineering projects that create lasting improvements (automation, reliability, tooling)
6 / 10
Code Review Comment: 'This script manually checks the status of deploy-service-a every hour. It's triggering alerts based on a simple regex match. Seems like a lot of overhead.' What does the reviewer *most* accurately mean by 'overhead' in this context?
The reviewer isn't just talking about server costs; they're highlighting the inefficiency. The regex match and hourly execution represent unnecessary complexity and a burden on the team's time. The term 'overhead' in SRE refers to tasks that consume engineering effort without directly contributing to value, like repetitive monitoring.
7 / 10
Slack Message from @sre-ops: 'Hey team, we've been tracking this incident with the payment-processor. It's largely due to manual intervention – manually restarting services after each failure, checking logs, and escalating. This is pure toil!' Which statement best captures @sre-ops's concern?
The key here is understanding that 'toil' isn't just about difficulty; it's about *effort* – specifically, effort that could be automated. Manual restarts and log checks are indicative of a process that consumes time without addressing the root cause or preventing future incidents. It highlights the need for proactive solutions.
8 / 10
PR Description: 'Automated deployment verification now includes running healthcheck-cli against production instances. This reduces the need for manual checks and provides immediate feedback.' Which of the following best explains *why* automating this verification is a reduction in toil?
The core of toil reduction is shifting repetitive tasks into automated processes. By automating the health check and providing immediate feedback, the PR eliminates the need for manual troubleshooting and reduces the time spent identifying and resolving deployment issues – that's precisely what SRE defines as toil.
9 / 10
Team Standup Update: 'I spent most of the week manually scaling up the database servers during peak hours. It's a pain and takes about 30 minutes per scale-up.' What does the engineer *primarily* want to address with this statement?
The engineer isn't complaining about the lack of servers; they're highlighting the *process* of manually scaling them. This manual intervention is time-consuming and doesn't contribute to a stable or efficient system – that's the essence of toil in this scenario. Addressing this inefficiency directly is the key goal.
10 / 10
API Response (from Monitoring System): '{"metric": "cpu_usage", "value": 95, "instance": "web-server-01", "timestamp": "2024-10-27T10:00:00Z"}' An SRE observes this response and notes it triggers a manual alert based on a predefined threshold. What does the automated alert *primarily* represent in terms of toil reduction?
The automated alert is *not* about proactive prevention. The fact that it triggers a manual response indicates that the monitoring system itself is contributing to toil – an engineer needs to react to the alert instead of the system automatically addressing the issue. Automation of this kind is where true toil reduction occurs.
What will I learn from the "Toil Reduction Language — SLO Engineering English | CoderLingo" exercise?
Practice the English vocabulary for toil identification and reduction: defining toil, quantifying time saved, toil tracking language, and making the case for automation to stakeholders.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this SLO Engineering exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss slo engineering topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more SLO Engineering exercises?
See the full SLO Engineering exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.