Intermediate
Estimation Language
#sla
#reliability
Reading SLAs & SLOs
6 exercises — interpret uptime percentages, error budgets, percentile latency targets (P99), and SLA breach language for engineers and stakeholders.
0 / 27 completed
1 / 27
An SLA states "99.9% uptime per month". Approximately how much downtime does this permit per month?
43 minutes — 99.9% uptime = 0.1% downtime per month.
Calculation:
• 1 month ≈ 30 days × 24 hours × 60 minutes = 43,200 minutes
• 0.1% of 43,200 = 43.2 minutes
Uptime → downtime reference table (per month):
Saying it in English:
• "99.9% uptime — that's three nines — permits about 43 minutes of downtime per month"
• "We're on a four-nine SLA, so we get fewer than 5 minutes downtime per month"
• "Each additional nine reduces your downtime budget by a factor of ten"
Calculation:
• 1 month ≈ 30 days × 24 hours × 60 minutes = 43,200 minutes
• 0.1% of 43,200 = 43.2 minutes
Uptime → downtime reference table (per month):
| SLA | Nines | Monthly downtime | Annual downtime |
|---|---|---|---|
| 99% | Two 9s | ~7.2 hours | ~87.6 hours |
| 99.9% | Three 9s | ~43 min | ~8.7 hours |
| 99.95% | Three-and-a-half 9s | ~21 min | ~4.4 hours |
| 99.99% | Four 9s | ~4.3 min | ~52 min |
| 99.999% | Five 9s | ~26 sec | ~5 min |
Saying it in English:
• "99.9% uptime — that's three nines — permits about 43 minutes of downtime per month"
• "We're on a four-nine SLA, so we get fewer than 5 minutes downtime per month"
• "Each additional nine reduces your downtime budget by a factor of ten"
2 / 27
What is the difference between an SLA, an SLO, and an SLI?
SLA / SLO / SLI — three layers of reliability measurement.
Definitions:
• SLI (Service Level Indicator) — the actual metric measured: "our API error rate is currently 0.3%"
• SLO (Service Level Objective) — the internal target: "we aim to keep the error rate below 0.5%"
• SLA (Service Level Agreement) — the external contract: "we promise customers 99.9% uptime; if we miss it, we issue credits"
Relationship:
Typical SLO is stricter than the SLA (internal target vs. external commitment):
• SLA: 99.9% uptime (customer promise)
• SLO: 99.95% uptime (internal target, with buffer)
• SLI: measured every minute from synthetic monitoring
How to use in conversation:
• "Are we within SLO?" — are we meeting our internal target?
• "We've breached the SLA" — we've violated the customer contract; credits may be due
• "The SLI is trending down — we may breach SLO by end of week"
• "What's the SLO for checkout latency?" — asking for the threshold
Error budget:
• Error budget = 100% − SLO = the allowed "bad time"
• "We've consumed 60% of our monthly error budget" — you have 40% left before SLO breach
Definitions:
• SLI (Service Level Indicator) — the actual metric measured: "our API error rate is currently 0.3%"
• SLO (Service Level Objective) — the internal target: "we aim to keep the error rate below 0.5%"
• SLA (Service Level Agreement) — the external contract: "we promise customers 99.9% uptime; if we miss it, we issue credits"
Relationship:
SLI (what we measure) → SLO (what we target) → SLA (what we promise)
Typical SLO is stricter than the SLA (internal target vs. external commitment):
• SLA: 99.9% uptime (customer promise)
• SLO: 99.95% uptime (internal target, with buffer)
• SLI: measured every minute from synthetic monitoring
How to use in conversation:
• "Are we within SLO?" — are we meeting our internal target?
• "We've breached the SLA" — we've violated the customer contract; credits may be due
• "The SLI is trending down — we may breach SLO by end of week"
• "What's the SLO for checkout latency?" — asking for the threshold
Error budget:
• Error budget = 100% − SLO = the allowed "bad time"
• "We've consumed 60% of our monthly error budget" — you have 40% left before SLO breach
3 / 27
A service has consumed 80% of its monthly error budget by day 20. What does this mean, and what would you say?
Option C — reads the error budget status correctly and draws an operational conclusion.
Error budget interpretation:
• Error budget = 100% − SLO uptime target
• For 99.9% SLO: error budget = 0.1% of month = ~43 minutes
• Consumed 80% of budget = used ~34 of those 43 minutes
• With 10 days left in the month, 80% consumed in 20 days → on track to double the allowed budget
Error budget language:
• "We've consumed X% of our error budget" — standard phrase
• "We're burning through our error budget" — informal, warns of fast consumption
• "Our error budget is exhausted" — 100% consumed; now in SLO breach
• "We have [X] minutes of error budget remaining" — quantified
• "Feature freeze until end of month" — a standard response to error budget depletion
• "error budget policy" — a team agreement about what happens when the budget is consumed
Why this matters:
The error budget creates a shared language between engineering and product. When it's high, teams can ship aggressively. When it's low, risky changes are frozen. This makes reliability a business conversation, not only a technical one.
Error budget interpretation:
• Error budget = 100% − SLO uptime target
• For 99.9% SLO: error budget = 0.1% of month = ~43 minutes
• Consumed 80% of budget = used ~34 of those 43 minutes
• With 10 days left in the month, 80% consumed in 20 days → on track to double the allowed budget
Error budget language:
• "We've consumed X% of our error budget" — standard phrase
• "We're burning through our error budget" — informal, warns of fast consumption
• "Our error budget is exhausted" — 100% consumed; now in SLO breach
• "We have [X] minutes of error budget remaining" — quantified
• "Feature freeze until end of month" — a standard response to error budget depletion
• "error budget policy" — a team agreement about what happens when the budget is consumed
Why this matters:
The error budget creates a shared language between engineering and product. When it's high, teams can ship aggressively. When it's low, risky changes are frozen. This makes reliability a business conversation, not only a technical one.
4 / 27
An SLA clause reads: "The latency SLO for the search API is P99 < 500ms." What does P99 mean, and how would you describe it?
P99 — the 99th percentile latency: 99% of requests complete faster than this threshold.
Percentile vocabulary:
• P50 (median) — 50% of requests are faster; the "typical" user experience
• P95 — 95% of requests are faster; fast users see this
• P99 — 99% of requests are faster; only 1 in 100 are slower
• P99.9 — 99.9% of requests are faster; 1 in 1,000 exceed this
• "tail latency" — informal term for P99 and above
How to describe SLOs in English:
• "Our P99 is 500ms — one in a hundred requests can take up to 500ms or more"
• "P50 is 80ms, but the tail latency (P99) is much higher at 1.2 seconds"
• "We need to bring the tail latency down — P99 is 4× our target"
• "The median is fine, but P95 and P99 are outliers suggesting specific slow paths"
Why P99 matters more than average:
At large scale, even 1% of requests = millions of bad user experiences. Optimising the average can hide severe tail latency. SLOs are typically set on P95 or P99 for APIs, and P99.9 for payment/critical paths. "Tail latency" is the enemy of consistent user experience.
Percentile vocabulary:
• P50 (median) — 50% of requests are faster; the "typical" user experience
• P95 — 95% of requests are faster; fast users see this
• P99 — 99% of requests are faster; only 1 in 100 are slower
• P99.9 — 99.9% of requests are faster; 1 in 1,000 exceed this
• "tail latency" — informal term for P99 and above
How to describe SLOs in English:
• "Our P99 is 500ms — one in a hundred requests can take up to 500ms or more"
• "P50 is 80ms, but the tail latency (P99) is much higher at 1.2 seconds"
• "We need to bring the tail latency down — P99 is 4× our target"
• "The median is fine, but P95 and P99 are outliers suggesting specific slow paths"
Why P99 matters more than average:
At large scale, even 1% of requests = millions of bad user experiences. Optimising the average can hide severe tail latency. SLOs are typically set on P95 or P99 for APIs, and P99.9 for payment/critical paths. "Tail latency" is the enemy of consistent user experience.
5 / 27
Your monitoring shows the service is at 99.94% availability over the past 30 days. Your SLO is 99.9%. How do you describe this status?
Option C — confirms SLO compliance, quantifies the margin, and translates the availability percentage into remaining error budget minutes.
Status report structure:
Calculation:
• 99.9% SLO = 43 min/month error budget
• Actual: 99.94% → downtime = 0.06% of 43,200 min = ~26 min used
• Remaining: 43 − 26 = ~17 minutes of error budget
Note on Option D: 99.94% is "three-and-a-half nines" (99.9X%), not six nines. Six nines would be 99.9999%.
Hedging SLO status language:
• "We're within SLO" — meeting the target
• "We're tracking toward an SLO breach" — moving in the wrong direction
• "We're in breach of SLO" — already failed the target
• "We have X minutes of error budget remaining" — quantified headroom
• "We're comfortably within SLO" — large margin
• "We're on the edge of our SLO" — close to the limit
• "We burned through our error budget in [X days]" — retrospective on a breach
Status report structure:
[Current measurement] against [SLO target] → [margin/headroom] Translated to: [X minutes used] of [Y minute budget] → [Z minutes remaining]
Calculation:
• 99.9% SLO = 43 min/month error budget
• Actual: 99.94% → downtime = 0.06% of 43,200 min = ~26 min used
• Remaining: 43 − 26 = ~17 minutes of error budget
Note on Option D: 99.94% is "three-and-a-half nines" (99.9X%), not six nines. Six nines would be 99.9999%.
Hedging SLO status language:
• "We're within SLO" — meeting the target
• "We're tracking toward an SLO breach" — moving in the wrong direction
• "We're in breach of SLO" — already failed the target
• "We have X minutes of error budget remaining" — quantified headroom
• "We're comfortably within SLO" — large margin
• "We're on the edge of our SLO" — close to the limit
• "We burned through our error budget in [X days]" — retrospective on a breach
6 / 27
How do you clearly explain an SLA penalty to a non-technical stakeholder?
Option B — explains the breach mechanism, quantifies the penalty in business terms, and confirms the notification obligation was met.
SLA breach communication structure:
• What happened: "uptime dropped below the contractual threshold" — specific but jargon-light
• Consequence: "triggering an automatic service credit" — describes the SLA mechanism
• Quantified impact: "10% of the monthly fee — approximately $2,400" — translates to business terms
• Contractual obligation met: "notified within the required 72-hour window" — shows compliance
SLA violation vocabulary:
• "SLA breach" / "SLA violation" — the event
• "service credit" — the typical remedy (percentage of monthly fee returned)
• "contractual threshold" — the agreed uptime level
• "downtime allowance" — the permitted downtime period
• "remediation period" — the time allowed to fix a breach before penalties apply
• "cure period" — legal term for the same
• "notification obligation" — contractual requirement to inform the customer within X hours
Distinguishing SLO vs. SLA breach:
• Internal SLO breach: "We missed our internal reliability target — no customer commitments violated, but we need to investigate"
• External SLA breach: "We violated a customer contract — credits are due, and we must generate an incident report"
SLA breach communication structure:
• What happened: "uptime dropped below the contractual threshold" — specific but jargon-light
• Consequence: "triggering an automatic service credit" — describes the SLA mechanism
• Quantified impact: "10% of the monthly fee — approximately $2,400" — translates to business terms
• Contractual obligation met: "notified within the required 72-hour window" — shows compliance
SLA violation vocabulary:
• "SLA breach" / "SLA violation" — the event
• "service credit" — the typical remedy (percentage of monthly fee returned)
• "contractual threshold" — the agreed uptime level
• "downtime allowance" — the permitted downtime period
• "remediation period" — the time allowed to fix a breach before penalties apply
• "cure period" — legal term for the same
• "notification obligation" — contractual requirement to inform the customer within X hours
Distinguishing SLO vs. SLA breach:
• Internal SLO breach: "We missed our internal reliability target — no customer commitments violated, but we need to investigate"
• External SLA breach: "We violated a customer contract — credits are due, and we must generate an incident report"
7 / 27
// Code Review Comment
During a code review for the new user authentication service, Sarah comments: 'This API response is returning a 502 error with a latency of 1.2 seconds 80% of the time. We need to ensure our SLAs are being met.'
Which of the following best explains Sarah's concern regarding this comment? Sarah's concern isn't simply about a 502 error; she's highlighting the *duration* of the failure and its impact on response time. A 1.2-second latency consistently occurring 80% of the time is almost certainly a violation of an SLA that likely specifies maximum latency or availability targets. The key here is understanding that SLAs aren't just about 'is it up?' but also about *how well* it's performing, and this comment flags a potential problem requiring immediate attention to prevent further service degradation.
8 / 27
// PR Description
Subject: Improve User Profile API Latency
This PR addresses performance concerns regarding the user profile API. We've optimized database queries and caching to reduce latency. Monitoring shows average response time is now 200ms, a significant improvement.
(Note: The current SLA for this API requires an average response time of < 300ms with 99.9% availability.)
Which statement best reflects the potential issue identified in this PR description?
Option A: The team has successfully met all performance targets and exceeded the SLA requirements. Option B: The optimized queries and caching have completely eliminated latency issues, guaranteeing compliance with the SLA. Option C: While improvements have been made, the PR doesn't explicitly address whether the new metrics still align with the 99.9% availability requirement defined in the SLA. Option D: The team intentionally prioritized speed over availability to achieve a lower average response time, disregarding potential SLA violations.
The correct answer (C) highlights the crucial point that simply reducing latency doesn't guarantee SLA compliance. An SLA often includes availability targets – if the optimized API now experiences increased errors or downtime due to the changes, it could still violate the SLA even with a lower average response time. Options A and B are overly optimistic; option D is intentionally misleading. The PR description focuses solely on latency without considering the broader availability implications defined in the service level agreement.
9 / 27
// Code Review Comment
During a code review for the new user authentication service, Sarah comments: 'This API response is returning a 502 error with a latency of 1.2 seconds 80% of the time. We need to ensure our SLAs are being met.'
Which of the following best explains Sarah's concern regarding this comment? Sarah's concern isn't simply about a 502 error; she's highlighting the *duration* of the failure and its impact on response time. A 1.2-second latency consistently occurring 80% of the time is almost certainly a violation of an SLA that likely specifies maximum latency or availability targets. The key here is understanding that SLAs aren't just about 'is it up?' but also about *how well* it's performing, and this comment flags a potential problem requiring immediate attention to prevent further service degradation.
10 / 27
// PR Description
Subject: Improve User Profile API Latency
This PR addresses performance concerns regarding the user profile API. We've optimized database queries and caching to reduce latency. Monitoring shows average response time is now 200ms, a significant improvement.
(Note: The current SLA for this API requires an average response time of < 300ms with 99.9% availability.)
Which statement best reflects the potential issue identified in this PR description?
Option A: The team has successfully met all performance targets and exceeded the SLA requirements. Option B: The optimized queries and caching have completely eliminated latency issues, guaranteeing compliance with the SLA. Option C: While improvements have been made, the PR doesn't explicitly address whether the new metrics still align with the 99.9% availability requirement defined in the SLA. Option D: The team intentionally prioritized speed over availability to achieve a lower average response time, disregarding potential SLA violations.
The correct answer (C) highlights the crucial point that simply reducing latency doesn't guarantee SLA compliance. An SLA often includes availability targets – if the optimized API now experiences increased errors or downtime due to the changes, it could still violate the SLA even with a lower average response time. Options A and B are overly optimistic; option D is intentionally misleading. The PR description focuses solely on latency without considering the broader availability implications defined in the service level agreement.
11 / 27
// Code Review Comment
During a code review for the new user authentication service, Sarah comments: 'This API response is returning a 502 error with a latency of 1.2 seconds 80% of the time. We need to ensure our SLAs are being met.'
Which of the following best explains Sarah's concern regarding this comment? Sarah's concern isn't simply about a 502 error; she's highlighting the *duration* of the failure and its impact on response time. A 1.2-second latency consistently occurring 80% of the time is almost certainly a violation of an SLA that likely specifies maximum latency or availability targets. The key here is understanding that SLAs aren't just about 'is it up?' but also about *how well* it's performing, and this comment flags a potential problem requiring immediate attention to prevent further service degradation.
12 / 27
// PR Description
Subject: Improve User Profile API Latency
This PR addresses performance concerns regarding the user profile API. We've optimized database queries and caching to reduce latency. Monitoring shows average response time is now 200ms, a significant improvement.
(Note: The current SLA for this API requires an average response time of < 300ms with 99.9% availability.)
Which statement best reflects the potential issue identified in this PR description?
Option A: The team has successfully met all performance targets and exceeded the SLA requirements. Option B: The optimized queries and caching have completely eliminated latency issues, guaranteeing compliance with the SLA. Option C: While improvements have been made, the PR doesn't explicitly address whether the new metrics still align with the 99.9% availability requirement defined in the SLA. Option D: The team intentionally prioritized speed over availability to achieve a lower average response time, disregarding potential SLA violations.
The correct answer (C) highlights the crucial point that simply reducing latency doesn't guarantee SLA compliance. An SLA often includes availability targets – if the optimized API now experiences increased errors or downtime due to the changes, it could still violate the SLA even with a lower average response time. Options A and B are overly optimistic; option D is intentionally misleading. The PR description focuses solely on latency without considering the broader availability implications defined in the service level agreement.
13 / 27
// Code Review Comment
During a code review for the new user authentication service, Sarah comments: 'This API response is returning a 502 error with a latency of 1.2 seconds 80% of the time. We need to ensure our SLAs are being met.'
Which of the following best explains Sarah's concern regarding this comment? Sarah's concern isn't simply about a 502 error; she's highlighting the *duration* of the failure and its impact on response time. A 1.2-second latency consistently occurring 80% of the time is almost certainly a violation of an SLA that likely specifies maximum latency or availability targets. The key here is understanding that SLAs aren't just about 'is it up?' but also about *how well* it's performing, and this comment flags a potential problem requiring immediate attention to prevent further service degradation.
14 / 27
// PR Description
Subject: Improve User Profile API Latency
This PR addresses performance concerns regarding the user profile API. We've optimized database queries and caching to reduce latency. Monitoring shows average response time is now 200ms, a significant improvement.
(Note: The current SLA for this API requires an average response time of < 300ms with 99.9% availability.)
Which statement best reflects the potential issue identified in this PR description?
Option A: The team has successfully met all performance targets and exceeded the SLA requirements. Option B: The optimized queries and caching have completely eliminated latency issues, guaranteeing compliance with the SLA. Option C: While improvements have been made, the PR doesn't explicitly address whether the new metrics still align with the 99.9% availability requirement defined in the SLA. Option D: The team intentionally prioritized speed over availability to achieve a lower average response time, disregarding potential SLA violations.
The correct answer (C) highlights the crucial point that simply reducing latency doesn't guarantee SLA compliance. An SLA often includes availability targets – if the optimized API now experiences increased errors or downtime due to the changes, it could still violate the SLA even with a lower average response time. Options A and B are overly optimistic; option D is intentionally misleading. The PR description focuses solely on latency without considering the broader availability implications defined in the service level agreement.
15 / 27
Code Review Comment
During a code review for the new payment processing service, David writes: 'The API is returning 5xx errors with an average latency of 750ms 90% of the time. We're failing to meet our SLA target.' Which statement best describes the issue David is highlighting?
David's comment correctly identifies a serious problem. The 90% latency metric, coupled with 5xx errors, signifies that the service is consistently failing to meet its performance objectives defined by the SLA. The incorrect options either downplay the severity or misinterpret the meaning of the reported metrics. This demonstrates understanding of how SLAs are triggered.
16 / 27
You're in a Slack channel discussing an issue with the user analytics dashboard. Another developer, Maria, sends this message: 'The SLO for page load time is P95 < 3 seconds. We're seeing some spikes up to 6 seconds. This is impacting user engagement.' What does Maria primarily mean by 'P95 < 3 seconds'?
Maria is using statistical terminology. 'P95 < 3 seconds' means that 95% of user sessions experienced a page load time *less* than 3 seconds. It's crucial to understand this isn't an absolute guarantee for every single user; it represents a probability distribution. The other options misinterpret the meaning of 'P95' as a fixed value or a description of the average.
17 / 27
Code Review Comment
During a code review for the new recommendation engine service, Ben comments: 'The API is returning 400 errors with an average latency of 900ms 85% of the time. This significantly exceeds our SLO.' What does 'exceeds our SLO' mean in this context?
'Exceeds our SLO' means that the service's performance metrics (in this case, latency and error rate) are *higher* than what was defined in the Service Level Objective. This indicates a failure to meet the agreed-upon standards for the service's operation. It's a direct consequence of not meeting the specified targets.
18 / 27
Code Review Comment
During a code review for the new payment processing service, David writes: 'The API is returning 5xx errors with an average latency of 750ms 90% of the time. We're failing to meet our SLA target.' Which statement best describes the issue David is highlighting?
David's comment correctly identifies a serious problem. The 90% latency metric, coupled with 5xx errors, signifies that the service is consistently failing to meet its performance objectives defined by the SLA. The incorrect options either downplay the severity or misinterpret the meaning of the reported metrics. This demonstrates understanding of how SLAs are triggered.
19 / 27
You're in a Slack channel discussing an issue with the user analytics dashboard. Another developer, Maria, sends this message: 'The SLO for page load time is P95 < 3 seconds. We're seeing some spikes up to 6 seconds. This is impacting user engagement.' What does Maria primarily mean by 'P95 < 3 seconds'?
Maria is using statistical terminology. 'P95 < 3 seconds' means that 95% of user sessions experienced a page load time *less* than 3 seconds. It's crucial to understand this isn't an absolute guarantee for every single user; it represents a probability distribution. The other options misinterpret the meaning of 'P95' as a fixed value or a description of the average.
20 / 27
Code Review Comment
During a code review for the new recommendation engine service, Ben comments: 'The API is returning 400 errors with an average latency of 900ms 85% of the time. This significantly exceeds our SLO.' What does 'exceeds our SLO' mean in this context?
'Exceeds our SLO' means that the service's performance metrics (in this case, latency and error rate) are *higher* than what was defined in the Service Level Objective. This indicates a failure to meet the agreed-upon standards for the service's operation. It's a direct consequence of not meeting the specified targets.
21 / 27
Code Review Comment
During a code review for the new payment processing service, David writes: 'The API is returning 5xx errors with an average latency of 750ms 90% of the time. We're failing to meet our SLA target.' Which statement best describes the issue David is highlighting?
David's comment correctly identifies a serious problem. The 90% latency metric, coupled with 5xx errors, signifies that the service is consistently failing to meet its performance objectives defined by the SLA. The incorrect options either downplay the severity or misinterpret the meaning of the reported metrics. This demonstrates understanding of how SLAs are triggered.
22 / 27
You're in a Slack channel discussing an issue with the user analytics dashboard. Another developer, Maria, sends this message: 'The SLO for page load time is P95 < 3 seconds. We're seeing some spikes up to 6 seconds. This is impacting user engagement.' What does Maria primarily mean by 'P95 < 3 seconds'?
Maria is using statistical terminology. 'P95 < 3 seconds' means that 95% of user sessions experienced a page load time *less* than 3 seconds. It's crucial to understand this isn't an absolute guarantee for every single user; it represents a probability distribution. The other options misinterpret the meaning of 'P95' as a fixed value or a description of the average.
23 / 27
Code Review Comment
During a code review for the new recommendation engine service, Ben comments: 'The API is returning 400 errors with an average latency of 900ms 85% of the time. This significantly exceeds our SLO.' What does 'exceeds our SLO' mean in this context?
'Exceeds our SLO' means that the service's performance metrics (in this case, latency and error rate) are *higher* than what was defined in the Service Level Objective. This indicates a failure to meet the agreed-upon standards for the service's operation. It's a direct consequence of not meeting the specified targets.
24 / 27
During a code review of the inventory management service, Alex writes: 'The API is returning 200 OK responses with an average latency of 500ms 95% of the time, but we're seeing occasional spikes to 1.5 seconds. This violates our SLO for order processing.' Which statement best reflects Alex's concern?
Alex's comment highlights a key issue: variability. While the average latency is acceptable (500ms), the occasional spikes to 1.5 seconds represent a breach of the SLO due to exceeding the defined threshold. The correct answer emphasizes the unacceptable latency *variability*, not just the overall average, which is crucial for SLAs.
25 / 27
You're in a Slack channel discussing a recent outage affecting the user notification service. John sends this message: 'Our P99 latency for sending push notifications is currently at 3 seconds – we're significantly over our agreed SLO of 0.5 seconds.' What does John primarily want to communicate?
John is raising a concern about non-compliance. He's directly pointing out that the P99 latency (the worst-case scenario) exceeds the defined SLO. While there *could* be an underlying issue, John's primary focus is on whether the service is meeting its contractual obligations.
26 / 27
Subject: Optimize API Gateway Response Times
This PR introduces rate limiting and caching to the API gateway. Monitoring shows that average response times have decreased from 800ms to 300ms under load, which is within our target of 400ms. The system now achieves 99% of its SLO for API request latency.
This PR successfully aligns with the defined SLO. The monitoring data clearly demonstrates that average response times have been reduced to within the target range (400ms) and that 99% of requests are meeting the latency requirement. This highlights the importance of quantifiable metrics in assessing SLA compliance.
27 / 27
During a daily stand-up, Emily reports: 'We've been seeing intermittent 503 errors on the payment processing service, with an average latency of 980ms 70% of the time. This is exceeding our SLO by a significant margin and impacting user transactions.' What action should Emily prioritize?
Emily needs to trigger an operational response. The intermittent 503 errors and exceeding SLO by a large margin indicate a critical issue requiring immediate attention from operations. While documentation is important, the priority should be swift investigation and remediation to mitigate the impact on user transactions.
Frequently Asked Questions
What does the "Reading SLAs & SLOs — Estimation Language Exercises" exercise cover?
Interpret uptime percentages, error budgets, percentile SLOs, and SLA penalty clauses. Practice reliability language for engineers. Intermediate exercises.
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.
How many questions are in "Reading SLAs & SLOs — Estimation Language Exercises"?
This exercise has 27 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Estimation Language exercises?
Browse the full Estimation Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.