5 exercises — Practice identifying toil, calculating ROI for automation, and communicating toil reduction strategy to leadership.
0 / 12 completed
1 / 12
An SRE team lead says in a planning meeting: "We need to quantify our toil so we can justify the automation work to leadership." Which of the following is the correct SRE definition of toil?
Google SRE defines toil using five criteria: manual, repetitive, automatable, reactive, and O(n) with growth.
The classic toil examples:
• Manually restarting services that crash on deploys
• Manually acknowledging recurring noisy alerts
• Running the same SQL query to fix data inconsistencies every week
• Manually rotating credentials on a schedule
Key distinction: toil is automatable. Hard engineering problems aren't toil just because they're difficult — toil is specifically work a script or automation could handle.
Key vocabulary:
• Toil — manual, repetitive, automatable, non-cumulative operational work
• O(n) scaling — toil that grows linearly as the service grows (more servers = more manual work)
• Toil budget — SRE teams target < 50% of time spent on toil; rest on engineering
• Enduring value — work that permanently improves the system (toil lacks this)
2 / 12
An SRE documents a recurring task: "Every Monday, an engineer spends 2 hours manually rotating API keys for the payment service across 12 environments. This has been done weekly for 8 months." How would you categorize this work and justify automation?
The ROI argument for toil elimination quantifies accumulated cost against automation investment.
The standard toil justification format:
1. "We spend X hours per week on this task"
2. "At our engineering rate, that's $Y/month in engineering time"
3. "Automating this would take Z hours of engineering investment"
4. "Payback period: Z ÷ X weeks"
In this example: 2h/week × 52 weeks/year = 104 hours/year of toil. A 20-hour automation investment pays back in under 2 months.
Key vocabulary:
• Toil ROI — return on investment calculation for automation work
• Payback period — weeks until automation recoups the engineering investment
• Toil accumulation — the growing backlog of hours spent on manual work
• Automation investment — one-time engineering effort to eliminate repeating toil
3 / 12
An engineering manager challenges an SRE: "Why do you track toil separately from other work? Isn't all operational work valuable?" What is the most accurate response?
The 50% cap on toil is a core SRE principle that protects the value proposition of the SRE role.
If SREs spend >50% of time on toil:
• Engineering capacity for automation shrinks
• Toil grows as the service grows
• The team burns out and loses engineers
• The SRE team becomes an operations team with a different name
The explicit measurement creates accountability: if toil consistently exceeds 50%, it's a signal to escalate to management for staffing or to negotiate scope.
Key vocabulary:
• 50% cap — SRE teams target no more than half of time on toil/ops work
• Engineering time — time spent on projects that permanently improve the system
• Toil vs. overhead — overhead (meetings, admin) is not the same as toil
• Ops work — broader than toil; includes on-call, incident response, change management
4 / 12
An SRE writes in a design document: "The proposed solution eliminates the deployment validation toil by implementing a self-healing mechanism — if the new pods don't respond to health checks within 2 minutes, the deployment automatically rolls back." What toil property does this address?
Self-healing and automation eliminate the "manual" property of toil — the defining characteristic.
Before: Engineer watches deployment → sees failed health checks → manually runs rollback command → confirms rollback → updates ticket.
After: Deployment controller watches → detects failed health checks → automatically rolls back → alerts team with context.
The engineer may still receive the alert (which is acceptable), but the manual execution work is eliminated.
This is a classic SRE automation pattern: replace human-in-the-loop with system-in-the-loop for predictable failure modes.
Key vocabulary:
• Self-healing — system automatically detects and corrects failures without human intervention
• Human-in-the-loop — requiring a human to take action; automating removes this
• Automated rollback — system-triggered reversion to previous state
• Toil elimination — permanently removing the need for a repetitive manual task
5 / 12
During quarterly planning, an SRE team presents their toil metrics: "Our toil has grown from 35% to 62% of team time over six months. The primary driver is alert noise — we're acknowledging 40–60 non-actionable alerts per day." What should the team's first priority be and how would they justify it?
Alert noise is a primary source of toil and the correct response is to fix the alerts, not add people.
Alert tuning approaches:
• Alert elimination: Delete alerts that never lead to meaningful action
• Alert consolidation: Group related symptoms into a single actionable alert
• Threshold adjustment: Tune thresholds to reduce false positives
• Actionability criterion: "Every alert must require a specific human action or it should not page"
Hiring more engineers to handle alert noise is an anti-pattern — it scales the team O(n) with the noise instead of eliminating the noise.
Key vocabulary:
• Alert noise — high volume of non-actionable alerts; a major source of toil
• Actionable alert — alert that requires a specific response; pages should only be actionable
• Alert fatigue — engineers stop paying attention after too many false alarms
• Alert tuning — engineering work to improve alert signal-to-noise ratio
6 / 12
A large e-commerce company is experiencing a surge in traffic due to a flash sale. Their database server is struggling to handle the load, resulting in slow response times and occasional timeouts. The operations team identifies this as 'toil' – repetitive, manual work that consumes valuable time and resources. Which of the following best describes this situation in terms of SLO engineering?
This scenario directly illustrates how excessive load (toil) violates an SLO. The server's inability to handle the increased traffic results in slow response times – a measurable deviation from the expected performance level defined by the SLO. This is a classic example of toil impacting service availability and user experience.
7 / 12
Sarah (Lead SRE): "Okay team, I've been reviewing the alerts for the last few days. We're spending a huge amount of time investigating false positives – things like intermittent network hiccups that never actually impact users. This is *toil*." Which of the following best describes Sarah's use of the term 'toil'?
The key here is Sarah's context. 'Toil' in SRE doesn't encompass *all* operational work. It specifically targets repetitive, low-value tasks that don't directly contribute to strategic goals or proactively prevent issues. The common misconception is that it's just about alerts; it's about the time spent *responding* to those alerts when they're not truly critical.
8 / 12
Mark (a junior engineer) posts this comment on a code review: 'This function is doing a lot of manual string parsing. It's not scalable and will break when we add more data fields. It feels like a lot of toil.' What does Mark *most likely* mean in this context?
Mark's use of 'toil' refers to manual, repetitive work that doesn't scale. He's highlighting a situation where effort is being expended unnecessarily – something SREs aim to reduce through automation. Option A is too broad; the issue isn't the language but the process itself. Options C and D are related issues but not the core definition of toil.
9 / 12
Liam (an SRE) sends this Slack message to his team: 'Hey everyone, I'm seeing a spike in alerts related to our microservice A. It seems like the service is intermittently failing and we're spending a lot of time manually restarting it. This feels like classic error budget exhaustion.' What does Liam *primarily* indicate?
Liam uses 'error budget exhaustion' to describe a situation where frequent, manual interventions are consuming the team's capacity to handle unexpected problems. This aligns directly with SLOs – if the service is failing frequently, it's exceeding its agreed-upon availability target. Options A and B focus on code fixes, not the overall operational state; option D addresses the alerting system but doesn't capture the core concept of an error budget.
10 / 12
PR Description: 'This pull request implements a new automated rollback mechanism for deployments to production. This will significantly reduce the time spent manually reverting failed deployments and minimize downtime – addressing a key driver of toil.' What is the *primary* benefit described in this PR justification?
The PR justifies its work by stating it reduces 'toil' – specifically the manual effort involved in rollback procedures. This directly addresses the goal of minimizing downtime and operational risk, which are core components of achieving an SLO for deployment reliability. Options A, C, and D represent secondary benefits that might arise as a result but aren't the primary justification.
11 / 12
Standup Update: 'Yesterday, we spent almost an hour manually investigating a spike in database query latency. We eventually traced it to a misconfigured index and fixed it. It was a lot of toil to diagnose and resolve.' What does this update *most accurately* convey?
The standup update highlights the manual effort – the 'toil' – involved in diagnosing and resolving the database latency issue. It's not about training or response time (though those may be related), but rather the fact that a routine operational problem required significant, manual investigation. This directly reflects a situation where the error budget is being consumed by unplanned work.
12 / 12
'The team's toil metrics have increased from 40% to 65% over the last quarter. This is primarily due to alerts that require investigation and manual remediation. We're struggling to maintain our SLO for system availability.' What does this situation *primarily* demonstrate?
The rise in toil metrics directly indicates that the team is spending a disproportionate amount of time addressing unplanned incidents – essentially consuming their error budget. This highlights the need to shift from reactive 'toil' (manual fixes) to proactive automation and preventative measures aligned with SLOs. Options A, B, and D are potential contributing factors but don't capture the core message about the unsustainable consumption of the error budget.
What will I learn from the "Toil & Automation Vocabulary — SLO & Error Budget Engineering English" exercise?
Practice the English vocabulary for identifying toil, quantifying its cost, and justifying automation investments in SRE and platform engineering contexts.
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 12 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 12 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.