Reliability questions are the part of an SRE or platform interview where fluent recitation is least convincing. Almost everyone can define SLI, SLO and SLA correctly. Very few can say what number they would pick, why, and what they would stop doing when it is missed — which is the entire point of the framework.
The three terms, and the one that matters
The SLI is the measurement: the proportion of events that were good. The SLO is the internal target for that measurement over a window. The SLA is the contractual promise, with financial consequences, and it is set looser than the SLO on purpose so that you breach your own target and react before you breach a customer's.
If your SLO and SLA are the same number, you have built yourself no warning.
The service level objective is the one that changes behaviour, and it does so through its inverse. A 99.9% target over 28 days permits roughly 43 minutes of failure. That allowance is the error budget, and treating it as a budget rather than a threshold is what turns reliability from an argument into arithmetic.
Writing an SLI that is worth measuring
Most weak answers stop at "availability." Availability of what, measured where?
A usable SLI has three parts: an event (an HTTP request, a job run, a page load), a criterion for good (status not 5xx, and served in under 300ms), and a measurement point. The measurement point is where interviewers push, because server-side metrics systematically miss the failures that never reached your server. A load balancer counting only requests it received cannot see the ones DNS or the network dropped, so an SLI measured at the application reports better numbers than users experience.
Common SLI shapes worth naming:
- Availability: successful requests over valid requests. Note "valid" — a client sending malformed requests should not burn your budget.
- Latency: requests served faster than a threshold, over total. Express it as a proportion, not an average. See tail latency for why averages hide the problem.
- Freshness: for pipelines, the proportion of data younger than some age.
- Correctness: the proportion of records processed without error, which is often the one that actually matters for a data platform.
Choosing the number
Do not pick nines because they sound serious. Three inputs decide it:
What users notice. If the mobile client retries once transparently, a single failure is invisible and only the second matters. That materially changes the target you need.
What your dependencies allow. Your availability cannot meaningfully exceed the floor set by everything you call synchronously. Four dependencies at 99.9% each, called in series, put you near 99.6% before you have written any bugs. If your proposed SLO is above that floor, you are committing to reliability you do not control — the fix is fewer synchronous dependencies, caching, or graceful degradation, and saying so is a strong answer.
What it costs. Each additional nine typically multiplies engineering effort. A target nobody will fund is worse than an honest lower one, because the team learns to ignore a permanently exhausted budget.
The practical method for a service that has never had an SLO: measure current performance for a few weeks, set the target near what you already achieve, publish it, and tighten later. An aspirational target on day one produces a budget that is always spent and an alert nobody believes.
What an error budget actually changes
This is the question that separates candidates who have used SLOs from candidates who have read about them.
While budget remains, teams ship. Risky migrations, aggressive rollouts and experiments are all funded by the budget. When it is exhausted, the policy is that feature releases stop and the effort goes to reliability until the window rolls forward.
That policy has to be agreed before it is needed, with whoever owns the roadmap. An error budget policy invented during an outage is a negotiation, not a policy — and interviewers who have lived through this will recognise whether you have.
The budget also improves alerting. Alerting on raw thresholds — "error rate above 1%" — pages for blips that no user noticed. Burn-rate alerting pages on the rate at which the budget is being consumed, typically with a fast burn condition for a severe short outage and a slow burn condition for a persistent low-grade problem. It pages on customer impact rather than on symptoms, which is why it produces fewer and better pages.
The questions, and what a complete answer covers
"What is the difference between an SLI, an SLO and an SLA?" Definitions, then the relationship that matters: the SLA is looser than the SLO so you find out first, and the SLO exists to produce an error budget.
"How would you set an SLO for this service?" Pick one user-facing journey rather than covering everything. Define the SLI from telemetry you actually have, measured as close to the user as possible. Measure current performance, set the target near it, agree the budget policy, iterate.
"Our SLO is 99.99% — thoughts?" Ask what the dependency floor is. Four nines is 4.3 minutes per month, which is less time than most deploy pipelines take to roll back. It is achievable only with a genuinely redundant architecture and an on-call rotation funded to match. Challenging the number politely is the correct answer here, not accepting it.
"The budget is exhausted mid-month. What happens?" Feature freeze per the agreed policy, and a look at what consumed it. If a single incident spent the month's budget, the follow-up is that incident's action items. If it was a steady drip, the service needs work that no single postmortem will surface.
"Do you need an SLO for every service?" No, and saying so is a good signal. SLOs are worth their overhead on services with real users and real decisions attached. An internal batch job with no consumer expectations gets monitoring, not a formal objective and a budget policy.
What separates a strong answer
Weak — correct and forgettable:
"An SLI is the indicator, the SLO is the objective, and the SLA is the agreement with the customer."
Strong:
"We'd measure the proportion of checkout requests returning non-5xx under 500ms at the edge, because our own metrics can't see failures that never reach us. I'd start at 99.9% since our payment provider is 99.95% and we call it synchronously — anything higher is a promise about somebody else's uptime. That gives about 43 minutes a month, and the agreed policy is that when half of it is gone by mid-month, the release train pauses."
The second answer contains a measurement point, a dependency argument, a number with a reason, and a decision. That combination is uncommon and it is exactly what the question is for.
Practice these
- Design a Distributed Tracing and Logging System — where the telemetry behind an SLI comes from
- Design a Metrics Monitoring and Alerting System — aggregation, cardinality, and why percentiles are hard to compute at scale
- Tell me about a time you dealt with a serious production incident — the behavioural counterpart, and where error budget policy shows up in practice
Related concepts: tail latency, service level objective, circuit breaker, NALSD.
Frequently asked questions
What is a good SLO target? There is no universal answer, and offering one is a trap. The target comes from what users notice, what your synchronous dependencies can support, and what the organisation will fund. For most user-facing web services the useful range is 99.9% to 99.95%; going higher is an architecture decision, not a dashboard one.
What is the difference between an error budget and a burn rate? The error budget is the total allowed unreliability in a window. The burn rate is how fast you are consuming it — a burn rate of 1 spends the budget exactly by the end of the window, and a burn rate of 14.4 spends a 30-day budget in about two days, which is why that figure appears in fast-burn alerts.
Should latency SLIs use averages or percentiles? Neither, strictly. The strongest form is a proportion: the fraction of requests faster than a threshold. It composes cleanly into an error budget, whereas a percentile does not average across windows in a mathematically meaningful way.
How long should the SLO window be? Four weeks is the common choice. It is long enough to smooth out single incidents and short enough that the budget resets on a timescale teams can plan around. Rolling windows react more smoothly than calendar months, which reset the budget abruptly on the first of the month.
Can an SLO be too low? Yes. An SLO substantially below what users expect gives you a budget you never spend, which means it never informs a decision — the same practical outcome as having no SLO at all.