An SRE says: "Our SLO is 99.9% availability, but the SLA with enterprise customers is 99.5%."
What distinguishes an SLO from an SLA?
The three-tier model: SLI → SLO → SLA. The SLO is intentionally tighter than the SLA — engineering targets 99.9% so that even with some error budget consumption, the 99.5% customer commitment is still honoured.
Term
Definition
Example
SLI
Service Level Indicator — the actual measured metric
% of requests returning 2xx
SLO
Service Level Objective — engineering's internal target
99.9% successful requests
SLA
Service Level Agreement — customer contract with financial penalties
99.5% — breach triggers credits
Key vocabulary: SLI/SLO/SLA hierarchy, SLA buffer (gap between SLO and SLA), customer commitment.
2 / 10
An SRE dashboard shows: "Error budget: 43% exhausted this month."
What is an error budget?
For a 99.9% availability SLO: error budget = 0.1% of requests can fail = approximately 43 minutes of downtime per month. If 43% is consumed, 0.043% of requests have failed so far this month — still 57% of the budget remains.
What does burn rate communicate in SRE error budget vocabulary?
Burn rate (from Google SRE): if burn rate = 1, the budget is being consumed at the rate that exactly exhausts it by the end of the window. Burn rate = 2 = budget exhausted in half the window. Used in multi-window alerting strategies.
Burn rate
Meaning
Window to exhaustion
1×
Normal — will exhaust budget at exactly end of window
Full window (e.g. 30 days)
2×
Alert — consuming budget twice as fast as allowed
Half window (e.g. 15 days)
14.4×
Fast burn — budget exhausted in 2 hours (page immediately)
An engineering manager says: "The team exhausted their error budget — per the SLO policy, they must pause feature work and focus on reliability."
What is the purpose of an error budget policy?
An error budget policy removes per-incident negotiation. The rules are pre-agreed calmly: when the budget is healthy → experiment freely; when it's low → be conservative; when it's exhausted → pause features, focus reliability. This removes ad-hoc friction.
Budget status
Policy action
100% remaining
Experiment freely — deploy, release, innovate
50% remaining
Caution — review deployment risk more carefully
0% remaining
Feature freeze — all effort on reliability and toil reduction
An SRE configures: "Alert fires when p99 latency > 500ms sustained for 5 minutes."
Which alerting principle does the "sustained for 5 minutes" condition implement?
Requiring a sustained period (5 minutes) reduces false positives — a brief p99 spike may be a single slow request. Only sustained degradation represents real user pain. This distinguishes symptom-based alerting from cause-based alerting.
Sarah (a junior developer) sends a Slack message to the team: "Hey everyone, I'm trying to improve the API response time for user authentication. The current p95 latency is consistently above 200ms. Should we prioritize this or continue with the planned feature rollout?"
The question tests understanding of how API latency relates to SLOs. Sarah's request highlights a potential violation – exceeding a key metric. Prioritizing fixes based on latency is the correct response as it directly addresses the performance target defined by the SLO.
7 / 10
During a standup meeting, Mark (the team lead) says: "We're currently at 65% of our error budget. We need to be very careful about adding new features or making significant changes to existing ones."
This question assesses understanding of the core function of an error budget. It's not about downtime or recovery time – it's a quantifiable limit on acceptable failures *before* impacting service levels. The budget dictates risk tolerance.
8 / 10
A code review comment from David (the senior developer) reads: "This change introduces a new logging statement that's firing every time the user updates their profile. The p99 latency is already high; this will likely exacerbate the problem."
The question focuses on the impact of new code additions on SLOs. David's comment correctly identifies that increased logging adds to latency, potentially violating the SLO, rather than a general statement about logging itself.
9 / 10
An API response from the backend service shows: `{"status": "error", "message": "Service unavailable - exceeding error budget."}`, and a status code of 503.
This question tests understanding of how an error budget manifests in a system. The 503 status code combined with the 'exceeding error budget' message clearly indicates the system is being throttled due to exceeding the defined limit.
10 / 10
Maria (an SRE) writes a PR description: "Implementing circuit breakers on this service to prevent cascading failures. This should improve resilience and reduce the likelihood of exceeding our error budget."
This question explores the relationship between resilience measures (like circuit breakers) and the error budget. While intended to improve reliability, poorly implemented circuit breakers can *increase* latency and therefore negatively impact the SLO – a key consideration when managing the budget.
What will I practise in "SLO & Error Budget Vocabulary"?
This module focuses on Performance Profiling — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Performance Profiling exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around performance profiling — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Performance Profiling exercises?
See the Performance Profiling hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.