5 exercises — Practice the language for writing and discussing SLO definitions: SLI selection, measurement windows, P99 latency targets, and target-setting conversations.
0 / 24 completed
1 / 24
An SRE is helping a team define their first SLO. They say: "We need to choose a good service level indicator before we can set any target." Which statement best explains what makes an SLI well-chosen?
SLI selection is user-centric: the indicator should measure what users actually experience, not what is easiest to instrument.
The four common SLI categories from Google's SRE book are:
• Availability — proportion of requests that succeeded (e.g., non-5xx responses)
• Latency — proportion of requests faster than a threshold (e.g., P99 < 300 ms)
• Quality — proportion of requests served with full quality (not degraded mode)
• Freshness — proportion of reads that returned data updated within a threshold
CPU and memory are resource metrics, not user-experience metrics — they are useful for capacity planning but not directly tied to what the user experiences. The SLI formula is always: good events / valid events, expressed as a percentage.
Key vocabulary:
• SLI (Service Level Indicator) — a quantitative measure of the service as experienced by the user
• good event — a request or interaction that met the quality bar
• valid event — any request that a correct service should be able to serve
• request-based SLI — measures individual requests rather than time-based uptime checks
2 / 24
A team is writing their SLO document. They draft: "Our p99 latency SLO is 200 ms." A senior SRE says the definition is incomplete. What is missing?
A complete SLO has three components: an SLI definition, a target percentage, and a measurement window.
A well-formed SLO statement looks like: "99% of valid API requests will complete with P99 latency below 200 ms, measured over a rolling 30-day window."
Without the measurement window, you cannot determine when the SLO is met or breached. Without an SLI definition, you cannot know which requests count. The "200 ms" target alone is ambiguous — it could mean the average, the median, or the maximum.
Common measurement windows: rolling 28 days (cleaner math), calendar month (easier stakeholder communication), or rolling 30 days (most common in practice).
Key vocabulary:
• measurement window — the time period over which the SLI is calculated (e.g., rolling 30 days)
• rolling window — a window that moves forward continuously, not tied to calendar boundaries
• P99 latency — the 99th percentile of request latency; 99% of requests are faster than this value
• target percentage — the minimum SLI value the team commits to maintaining
3 / 24
During an SLO review, an engineer says: "We need to tighten our availability SLO from 99.9% to 99.95%." A product manager asks what "tightening an SLO" means and what consequences it has. Which explanation is correct?
Tightening an SLO always shrinks the error budget, which directly constrains how much unreliability the team can tolerate.
The impact of tightening from 99.9% to 99.95%:
• 99.9% SLO: error budget = 0.1% × 43,200 min = 43.2 min/month
• 99.95% SLO: error budget = 0.05% × 43,200 min = 21.6 min/month
Half the budget means: fewer incidents allowed before breach, less time for planned maintenance, more careful deployment practices. This is why SLO target-setting requires input from both engineering (what is achievable) and product (what reliability customers actually need).
Key vocabulary:
• tighten an SLO — raise the reliability target, reducing the error budget
• relax an SLO — lower the reliability target, increasing the error budget
• SLO aspirational vs. achievable — the target must reflect what the service can actually sustain
• reliability investment — engineering effort required to meet and maintain a given SLO
4 / 24
A team writes in their runbook: "Our checkout service SLI is: the proportion of checkout requests that complete successfully and return an order confirmation within 3 seconds." An SRE reviewer says this is a good SLI definition. Why?
The best SLIs capture the complete user experience in a single ratio — combining the success criterion with a latency threshold eliminates the blind spot where a slow-but-successful response is counted as "good."
This type of combined SLI is sometimes called a "happy path SLI" — the request is only "good" if it completes the full user journey (received a meaningful response) within an acceptable time.
Compare two definitions:
• Weak: "proportion of requests returning HTTP 200" — a 200 after 30 seconds counts as good
• Strong: "proportion of requests returning an order confirmation within 3 seconds" — captures both correctness and performance
Key vocabulary:
• combined SLI — a single indicator measuring both success and latency together
• user journey — the complete sequence of steps a user takes to accomplish a goal
• latency threshold — the maximum acceptable response time (e.g., 3 seconds for checkout)
• happy path — the sequence of steps where everything works as expected
5 / 24
An SRE writes the following in a design doc: "Target-setting language for SLOs should be based on user research and historical baseline, not engineering intuition." A teammate asks what this means in practice. Which answer is correct?
SLO target-setting is a negotiation between what is achievable (history) and what matters to users (research), not an arbitrary number chosen by engineers.
The standard approach:
1. Baseline: review 90 days of historical SLI data — what has the service actually delivered?
2. User research: what is the threshold at which users notice or are affected by degradation? (Often from A/B tests, support tickets, abandonment data)
3. Target: set the SLO slightly below the historical baseline to allow room for incidents, but above the user-impact threshold
Common phrase: "Our current baseline is 99.96%, users are impacted below 99.9%, so we set our SLO at 99.9% with room to tighten later."
Key vocabulary:
• historical baseline — what reliability the service has actually achieved over a past period
• user impact threshold — the reliability level below which user experience measurably degrades
• aspirational SLO — a target above the current baseline; requires investment to achieve
• conservative SLO — a target below the baseline; gives flexibility but may under-represent user needs
6 / 24
// Code Review Comment
"This SLI calculation seems overly sensitive. The p95 latency is consistently below 100ms, and this threshold feels arbitrary."
This scenario tests understanding of how to challenge an SLI definition constructively. The engineer is validly questioning a potentially overly restrictive threshold based on observed data. It's about ensuring the SLI truly reflects user experience and business impact, not arbitrary values. Option B misinterprets the comment as a simple preference.
7 / 24
Sarah, a junior engineer, asks her manager: "What does 'SLO engineering' really mean? I keep hearing about SLOs, but I'm not sure how it relates to my code."
SLO engineering goes beyond simply defining SLIs. It's a holistic approach that uses metrics to understand *how* users experience your application and identify opportunities for improvement in reliability and performance. This involves correlating technical metrics with user-reported issues or business outcomes.
8 / 24
A Slack message from an SRE: 'Okay team, let's aim for a 99.95% availability SLO. That's going to require some serious investment in redundancy and automated failover.' What does the SRE mean by 'requiring some serious investment'?
When an SRE states that achieving a higher SLO requires 'serious investment,' they're indicating that it demands significant resources – likely in redundancy, automated failover mechanisms, and potentially infrastructure upgrades – to actively reduce the probability of downtime. It's about proactively managing risk.
9 / 24
A PR description for a new feature includes: 'This update improves the API response time by reducing database queries.' Which of the following is the MOST relevant SLI to measure the impact of this change?
While reducing database queries is a good change, the *most* relevant SLI to measure its impact is API response latency. This directly reflects the user experience and provides a quantifiable metric for assessing whether the update was successful in improving performance.
10 / 24
During a standup meeting, an engineer states: 'We're aiming for a 99.9% availability SLO for our core service.' A senior SRE asks, 'What does that really *mean* to the user?' What is the SRE most likely probing for?
SLOs aren't just technical targets; they must be tied to user impact. The SRE is questioning whether the 99.9% availability SLO translates into a measurable difference for users – how many are affected when downtime occurs and what business consequences result from that disruption.
11 / 24
Sarah, a junior engineer, asks her manager: "What does 'SLO engineering' really mean? I keep hearing about SLOs, but I'm not sure how it relates to my code."
SLO engineering goes beyond simply defining SLIs. It's a holistic approach that uses metrics to understand *how* users experience your application and identify opportunities for improvement in reliability and performance. This involves correlating technical metrics with user-reported issues or business outcomes.
12 / 24
A Slack message from an SRE: 'Okay team, let's aim for a 99.95% availability SLO. That's going to require some serious investment in redundancy and automated failover.' What does the SRE mean by 'requiring some serious investment'?
When an SRE states that achieving a higher SLO requires 'serious investment,' they're indicating that it demands significant resources – likely in redundancy, automated failover mechanisms, and potentially infrastructure upgrades – to actively reduce the probability of downtime. It's about proactively managing risk.
13 / 24
A PR description for a new feature includes: 'This update improves the API response time by reducing database queries.' Which of the following is the MOST relevant SLI to measure the impact of this change?
While reducing database queries is a good change, the *most* relevant SLI to measure its impact is API response latency. This directly reflects the user experience and provides a quantifiable metric for assessing whether the update was successful in improving performance.
14 / 24
During a standup meeting, an engineer states: 'We're aiming for a 99.9% availability SLO for our core service.' A senior SRE asks, 'What does that really *mean* to the user?' What is the SRE most likely probing for?
SLOs aren't just technical targets; they must be tied to user impact. The SRE is questioning whether the 99.9% availability SLO translates into a measurable difference for users – how many are affected when downtime occurs and what business consequences result from that disruption.
15 / 24
Reviewer Comment:
"The current SLI for 'successful transactions' is simply a boolean flag. This doesn't tell us *how* successful they are, or if there are underlying issues impacting the overall user experience. What would be a more robust approach?"
The reviewer correctly identifies that a simple boolean SLI lacks crucial context. A good SLI should provide *how* successful transactions are, not just whether they completed. The options highlight the limitations of a basic flag and suggest alternative approaches for more sophisticated monitoring.
16 / 24
SRE Message:
"Hey team, we're aiming for a 99.5% uptime SLO for the payment gateway. To achieve this, we need to aggressively reduce our MTTR – ideally below 15 minutes. What immediate actions can we take to address potential bottlenecks impacting recovery times?"
The SRE is directly linking the availability SLO to a key metric – MTTR. This demonstrates how SLIs drive operational decisions. The options highlight why focusing on MTTR reduction is critical for meeting the target uptime and understanding the connection between availability and recovery time.
17 / 24
PR Description:
"This commit refactors the user authentication service to improve performance. The new code utilizes a more efficient caching strategy, leading to reduced API response times."
The PR description focuses on *how* the change was made (caching) rather than *what* it will measure. A good SLI should directly relate to user experience or service availability. The options correctly identify that response time is a potential metric but emphasizes the need for quantification.
18 / 24
Engineer Statement:
"We're targeting a 99.9% availability SLO for our core API. This means we'll need to prioritize proactive monitoring and automated scaling to handle peak loads."
The engineer's statement correctly identifies a key element for achieving an availability SLO: proactive monitoring. Monitoring allows teams to identify issues *before* they impact users. The other options highlight potential pitfalls – automatic scaling alone isn't sufficient and the statements are largely synonymous.
19 / 24
SRE Message:
"Team, we need to move our current SLO for 'successful data syncs' from a 98% target to 99.7%. This requires us to consider the impact on downstream systems and implement more robust error handling – it's going to be a significant engineering effort."
The SRE's message highlights the need for more than just a numerical target. Improving an SLO often requires deeper investigation into the root causes of failures and implementing appropriate safeguards. The options correctly identify what's necessary to achieve a higher availability target.
20 / 24
Reviewer Comment:
"The current SLI for 'successful transactions' is simply a boolean flag. This doesn't tell us *how* successful they are, or if there are underlying issues impacting the overall user experience. What would be a more robust approach?"
The reviewer correctly identifies that a simple boolean SLI lacks crucial context. A good SLI should provide *how* successful transactions are, not just whether they completed. The options highlight the limitations of a basic flag and suggest alternative approaches for more sophisticated monitoring.
21 / 24
SRE Message:
"Hey team, we're aiming for a 99.5% uptime SLO for the payment gateway. To achieve this, we need to aggressively reduce our MTTR – ideally below 15 minutes. What immediate actions can we take to address potential bottlenecks impacting recovery times?"
The SRE is directly linking the availability SLO to a key metric – MTTR. This demonstrates how SLIs drive operational decisions. The options highlight why focusing on MTTR reduction is critical for meeting the target uptime and understanding the connection between availability and recovery time.
22 / 24
PR Description:
"This commit refactors the user authentication service to improve performance. The new code utilizes a more efficient caching strategy, leading to reduced API response times."
The PR description focuses on *how* the change was made (caching) rather than *what* it will measure. A good SLI should directly relate to user experience or service availability. The options correctly identify that response time is a potential metric but emphasizes the need for quantification.
23 / 24
Engineer Statement:
"We're targeting a 99.9% availability SLO for our core API. This means we'll need to prioritize proactive monitoring and automated scaling to handle peak loads."
The engineer's statement correctly identifies a key element for achieving an availability SLO: proactive monitoring. Monitoring allows teams to identify issues *before* they impact users. The other options highlight potential pitfalls – automatic scaling alone isn't sufficient and the statements are largely synonymous.
24 / 24
SRE Message:
"Team, we need to move our current SLO for 'successful data syncs' from a 98% target to 99.7%. This requires us to consider the impact on downstream systems and implement more robust error handling – it's going to be a significant engineering effort."
The SRE's message highlights the need for more than just a numerical target. Improving an SLO often requires deeper investigation into the root causes of failures and implementing appropriate safeguards. The options correctly identify what's necessary to achieve a higher availability target.
What will I learn from the "SLO Definition Vocabulary — SLO Engineering English | CoderLingo" exercise?
Practice the English vocabulary for writing and discussing SLO definitions: SLI selection, target-setting language, P99 latency SLOs, measurement windows, and tightening targets.
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 24 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 24 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.