5 exercises — Practice communicating reliability posture to leadership, enterprise customers, and product teams: framing metrics, transparency, and outlier reporting.
0 / 10 completed
1 / 10
An SRE is presenting the monthly reliability summary to the VP of Engineering. They say: "The checkout service maintained 99.94% availability — consuming 28% of our error budget — across 2.3 billion requests this month." Why is mentioning the request volume important in this context?
Contextualizing reliability metrics with scale makes abstract percentages meaningful.
"99.94% availability" sounds modest. But at 2.3 billion requests/month:
• 0.06% failure rate = ~1.38 million failed requests
• Achieving 99.94% means ~2.299 billion requests served correctly
Scale context transforms the number from an abstract percentage into a demonstration of engineering quality at a tangible scale.
Other useful context:
• Traffic patterns (e.g., "including 3 major sale events")
• Comparison to industry benchmarks
• Trend over time ("up from 99.87% last month")
Key vocabulary:
• Reliability at scale — framing availability in terms of absolute request counts
• Scale context — volume information that makes percentage metrics meaningful
• Availability numerator — the "good requests" count behind the percentage
• Trend framing — comparing current to previous period to show direction
2 / 10
A VP asks an SRE: "Is 99.9% availability good enough, or should we be targeting 99.99%?" What is the best way to structure the response?
Reframing from capability to business impact demonstrates SRE maturity to leadership.
The cost-benefit framing:
• Cost of 99.99% vs. 99.9%: additional infrastructure, engineering, operational complexity
• Benefit: preventing the ~8 additional hours of downtime per year
• Question: what is 8 hours of downtime worth in lost revenue, customer trust, SLA penalties?
This framing ensures SLO decisions involve business stakeholders and are grounded in real value — not just technical preference.
Key vocabulary:
• Cost of reliability — engineering and infrastructure cost to achieve a given SLO
• Cost of downtime — revenue, reputation, and contractual cost of reliability failures
• Reliability ROI — the return on investment of improving the SLO
• Breakeven SLO — the point where cost of reliability equals the cost of downtime
3 / 10
After a major incident, a product manager says: "We need to reassure users. Can you send a public message saying we're at five-nines reliability?" An SRE responds: "That would be misleading." What should the accurate communication include?
Reliability communications must be grounded in measured data, not aspirational claims.
A well-crafted post-incident reliability statement:
• States the measured availability for the affected period
• Acknowledges the incident and its duration
• Quantifies the impact (users affected, transactions failed)
• Describes current state and what's been fixed
• Outlines preventive measures going forward
Claiming "five nines" after a significant incident is a trust-breaking move — users will check the status history and see the gap.
Key vocabulary:
• Post-incident communication — public or stakeholder-facing reliability summary after an incident
• Measured availability — actual recorded percentage based on SLI data
• Aspirational claim — stating a target as a fact (misleading)
• Reliability transparency — honest communication about actual vs. target reliability
4 / 10
In a quarterly business review, an SRE lead presents: "Our services collectively maintained 99.91% average availability, but that average hides a critical outlier: the payment gateway had 99.2% availability, well below its 99.95% SLO." What communication principle does this demonstrate?
Aggregate averages can mask critical failures in high-value services — always surface outliers explicitly.
99.91% aggregate sounds healthy. But if the payment gateway is at 99.2%, that's translating directly into lost transactions and potential SLA breaches with enterprise customers.
Effective reliability communication to executives:
• Show aggregate health for context
• Explicitly call out services below SLO
• Quantify business impact of each outlier
• End with a mitigation plan or ask
Key vocabulary:
• Aggregate reliability — combined availability metric across multiple services
• Outlier service — individual service significantly below or above the aggregate
• Below-SLO service — service whose actual reliability fell below its target
• Critical path service — high-business-impact service (like payment) that warrants special attention
5 / 10
A customer success manager asks an SRE: "Enterprise customer Acme Corp is asking about our reliability posture before renewing their contract. What should I tell them?" What vocabulary and framing should the SRE provide?
Sophisticated enterprise customers value measured history, process maturity, and transparency over marketing claims.
Option D's four-part structure is effective:
1. Historical data — measured reliability shows real capability
2. Incident transparency — number of incidents and MTTR demonstrates mature incident response
3. Process demonstration — explaining the error budget policy shows systematic reliability management
4. Forward roadmap — reliability roadmap demonstrates commitment to improvement
This framing builds trust through transparency rather than through optimistic claims.
Key vocabulary:
• Reliability posture — overall state of a system's reliability including process maturity
• MTTR — mean time to recovery; key metric for incident response quality
• Postmortem transparency — sharing incident reviews publicly or with customers
• Reliability roadmap — planned investments to improve availability over time
6 / 10
During a code review for the new user onboarding flow, Sarah (the Lead Frontend Developer) comments on a pull request: 'This API call to /users/{userId} has an error budget of 10%. That's quite high – what does that actually *mean*?' Which of the following best explains Sarah's concern?
Sarah is rightly concerned about the error budget. The error budget represents the allowable percentage of errors for that specific API call. A high percentage signifies a potential problem with reliability – if this call consistently exceeds 10% error rate, it's negatively impacting the user onboarding experience and violating the SLO.
7 / 10
Mark (SRE) is responding to a question in a Slack channel from a junior developer, Alex: 'Hey Mark, I'm seeing a lot of errors on the image upload service. Is that bad?' What's the *most* helpful response Mark should send?
Alex needs context, not just a judgment. Mark should frame the issue in terms of the error budget and usage volume. This allows Alex to understand the severity of the problem relative to the system's overall reliability goals. Simply stating 'it's terrible' is unhelpful and doesn't provide actionable information.
8 / 10
You are drafting a PR description for a deployment that includes an updated SLO for the 'Recommendations' service. The new SLO is 99.95% availability with an error budget of 0.1%. Which of the following best describes how you should phrase this change in the PR?
The PR description needs to clearly communicate both the new SLO and the associated error budget. Using precise language – '99.95% availability, with a small error budget' – is crucial for transparency and understanding. It sets expectations and allows stakeholders to assess the impact of this change.
9 / 10
During the daily stand-up, David (SRE) says: 'We're maintaining our 99.98% availability target for the core payment service, but we're using almost all of our error budget.' What does David *most* need to convey to the team?
David needs to highlight the critical situation: near-exhaustion of the error budget. This signals an impending risk—if the payment service continues to experience errors at this rate, it will violate its SLO and potentially cause significant disruption. The team needs to understand the urgency.
10 / 10
The API returns the following response for a request to check the status of an order: `{"status": "processing", "error_budget_usage": 0.85, "request_volume": 12345}`. What does the `error_budget_usage` value primarily indicate?
The `error_budget_usage` value is a critical metric reflecting the proportion of errors occurring within the defined error budget for that particular request. It's directly linked to the service's reliability and whether it's meeting its SLO targets – a high percentage suggests a problem.
What will I learn from the "Reliability Communication Language — SLO & Error Budget Engineering English" exercise?
Practice the English for communicating reliability metrics to leadership, product managers, and enterprise customers: framing, transparency, outlier reporting, and trust-building.
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.