5 exercises — Practice the language of reliability reports: availability statements, contributing factors, action items, trends, and translating technical metrics for business stakeholders.
0 / 10 completed
1 / 10
An SRE writes in the weekly reliability report: "We achieved 99.95% availability this week." A colleague asks what "availability" means precisely in this context. Which explanation is most accurate?
In SRE reporting, "availability" is almost always a request-based SLI — the percentage of valid user requests that were successfully served — not a simple uptime check.
The distinction matters when communicating to stakeholders:
• Uptime-based: "The server was up 99.95% of the week" — says nothing about whether requests succeeded
• Request-based: "99.95% of requests were served successfully" — directly reflects user experience
When writing a reliability report, always clarify which definition you are using. The standard in modern SRE practice is the request-based definition, because it corresponds to the SLI that drives the error budget.
Key vocabulary:
• availability — proportion of successful requests to total valid requests; expressed as a percentage
• request-based availability — measures individual requests, not server uptime
• uptime — the fraction of time a server or service was running; less precise than request-based availability
• SLI-based reporting — reliability reporting grounded in the same metrics used for the SLO
2 / 10
In a weekly reliability report, the section titled "Contributing Factors" lists: "1. Increased traffic from the EU launch. 2. A misconfigured load balancer rule deployed on Tuesday. 3. A dependency on the payments API that had elevated error rates." What does "contributing factors" mean in this context?
"Contributing factors" is the standard section in a reliability report that explains the causes behind the week's reliability numbers — it connects the data (availability percentage) to the reasons (what happened).
A well-written contributing factors section:
• Names specific events (not vague: "there were some issues")
• Distinguishes between root causes (misconfigured load balancer) and context (EU launch traffic increase)
• Notes external dependencies that affected reliability (payments API)
• Provides enough detail for stakeholders to understand without requiring engineering background
Typical categories of contributing factors:
• Deployment-induced: configuration changes, code deployments
• Traffic-induced: unexpected demand spikes, new market launches
• Dependency-induced: third-party or internal service degradation
• Infrastructure-induced: hardware failures, cloud provider incidents
Key vocabulary:
• contributing factors — the causes and conditions that shaped the reliability outcome for the period
• root cause — the primary technical reason an incident or degradation occurred
• external dependency — a third-party or internal service the team relies on but does not control
• deployment-induced degradation — a reliability issue caused by a code or configuration change
3 / 10
At the end of a weekly reliability report, there is a section called "Action Items." The report lists: "1. Investigate the payments API dependency (owner: Alex, due: Friday). 2. Add latency alerting for the EU region (owner: Priya, due: next Monday). 3. Review load balancer configuration with the platform team (owner: Team, due: end of quarter)." What is the purpose of action items in a reliability report?
Action items are the operational output of a reliability report — they close the loop between observing a reliability problem and actually fixing the underlying cause.
The three elements of a good action item:
1. Specific: "Investigate the payments API dependency" — not "look at dependencies"
2. Owned: assigned to a named person (Alex, Priya) or team
3. Time-bound: due date is explicit (Friday, next Monday, end of quarter)
Without owners and due dates, action items become a "nice to have" list that never gets done. The reliability report becomes a mechanism for accountability when action items carry real owners and deadlines.
A well-structured weekly reliability report typically has:
• Availability summary (the number)
• Incidents and contributing factors (the story)
• Action items (the response)
• Trend data (is availability improving over time?)
Key vocabulary:
• action items — specific, owned, time-bound tasks following from reliability findings
• owner — the named person responsible for completing an action item
• due date — the deadline by which an action item must be completed
• follow-through — completing the action items from a previous report; reviewed at the start of the next report
4 / 10
An SRE presents a monthly reliability summary to leadership. The slide reads: "April availability: 99.97% (target: 99.9%). Three incidents — all resolved within SLO. Error budget consumed: 18%. Trend: improving month-over-month for the third consecutive month." Which sentence from this report is most important for a business audience to understand?
For business stakeholders, the trend line is more actionable than any single data point — consistent improvement signals that the SRE investment is working, while a flat or declining trend signals a structural problem.
How each metric reads to different audiences:
• Availability number: engineers care about this; executives understand it but need context (what is the target?)
• Incident count: useful context but can be misleading — 10 minor incidents might be less harmful than 1 major one
• Error budget consumed: important for engineering and product teams making deployment decisions
• Trend: the most compelling narrative for leadership — "we are improving" or "we need investment"
When presenting reliability to a non-technical audience, lead with the trend and frame the number in context of the target. "We exceeded our 99.9% target for the third consecutive month, with error budget consumption well below 50%" is a complete, reassuring story.
Key vocabulary:
• reliability trend — the direction of reliability change over multiple reporting periods
• month-over-month improvement — availability or error rate improving compared to the previous month
• within SLO — the service met or exceeded its reliability target for the period
• reliability posture — the overall state of a service's reliability, often communicated as a trend narrative
5 / 10
A weekly reliability report states: "This week we achieved 99.92% availability against a 99.9% target. The primary contributing factor was elevated error rates from the payment gateway between 14:00 and 16:30 UTC on Wednesday, during which approximately 0.3% of checkout requests failed. Action items: (1) engage the payment gateway vendor, (2) implement circuit breaker for gateway timeouts." Which phrase in this report is an example of stakeholder-facing language (not raw technical jargon)?
"Approximately 0.3% of checkout requests failed" is stakeholder language because it connects the reliability metric to a specific user action (checkout) that business stakeholders care about — it makes the abstract concrete.
The translation from technical to stakeholder language:
• Technical: "SLI dropped below the error budget threshold during the payment gateway incident"
• Stakeholder: "0.3% of checkout attempts failed for 2.5 hours on Wednesday"
Why the checkout framing works:
• Product managers understand checkout conversion rates
• Business stakeholders can estimate revenue impact
• Customer support teams can anticipate complaint volume
"Circuit breaker" is engineering jargon; a stakeholder would need an explanation. "Elevated error rates" is vague — how many users were affected? "99.92% availability" needs context (is that good or bad?). The checkout failure number is immediate and interpretable without SRE background.
Key vocabulary:
• stakeholder-facing language — reliability communication translated into business or user impact terms
• user impact statement — describes how many users were affected and in what way
• concrete metric — a number tied to a specific, understandable user action (not an abstract SLI value)
• reliability narrative — a structured story connecting the data, cause, and response in plain language
6 / 10
Alex writes in a Slack channel: 'The SLO for the CheckoutService is 99.9% availability. We're currently at 99.8%. Feels like we're slipping.' What does 'slipping' mean in this context?
'Slipping' refers to a degradation of performance relative to a defined Service Level Objective (SLO). It indicates that the current availability is falling below the target threshold – in this case, 99.9%. This term highlights a critical issue needing immediate attention and doesn't just mean a simple failure; it signifies a trend.
7 / 10
A PR description reads: 'Implemented a new retry mechanism for the API calls to the third-party authentication service. This should reduce transient errors and improve overall reliability.' What is the primary purpose of this change, according to this description?
The description focuses on 'reducing transient errors' and 'improving overall reliability.' This indicates that the retry mechanism is designed to address temporary issues (like network glitches or brief service outages) – a core principle of building resilient systems. The goal isn't just throughput but dependable operation.
8 / 10
During a standup meeting, Priya says: 'We're tracking our error budget consumption closely. We've used 15% this month, which is above the expected 10%. This suggests we need to investigate potential root causes.' What does 'error budget consumption' refer to?
An 'error budget' is a defined allowance for errors within an SLO. It represents the amount of downtime or failed requests that a service can tolerate without breaching its target availability. Tracking consumption highlights whether the system is operating within acceptable limits and signaling potential problems.
9 / 10
A reliability report states: 'The primary driver of increased latency was a bottleneck in our data processing pipeline. We've identified the root cause and implemented optimizations.' What does 'bottleneck' represent in this context?
A 'bottleneck' describes a situation where limited resources (like bandwidth, CPU, or memory) are overwhelmed by the volume of traffic or operations, causing delays and performance degradation. This is a common term in system performance analysis and highlights a specific constraint impacting overall reliability.
10 / 10
Ben, an SRE, is explaining the findings of the monthly report to stakeholders. He says: 'Our service availability remained strong at 99.98%, demonstrating consistent performance and a proactive approach to risk mitigation.' What does 'risk mitigation' mean in this statement?
'Risk mitigation' refers to proactive actions taken to lessen the chances of an incident occurring or to minimize its impact if one does happen. This demonstrates a systematic approach to reliability – anticipating potential problems and taking steps to avoid them, rather than simply reacting to failures.
What will I learn from the "Reliability Reporting Vocabulary — SLO Engineering English | CoderLingo" exercise?
Practice the English vocabulary for reliability reporting: availability statements, contributing factors, action items, and communicating reliability trends to business 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.