An SLO is a target for a reliability metric over a window — for example 99.9% of requests under 300ms in 28 days — and the error budget it implies.
If you have thirty seconds to answer
An SLO is a target for a service level indicator over a window — for example, 99.9% of requests served under 300 milliseconds across 28 days. The SLI is the measurement, the SLO is the internal target, and the SLA is the contractual promise, always set looser than the SLO so you find out first. The point of an SLO is the error budget it creates: the allowed unreliability becomes a budget you spend on releases, and when it is exhausted you stop shipping features and fix reliability.
Definition
A service level objective is an explicit reliability target for a measurable indicator of service health, stated over a time window. The indicator itself is the SLI (service level indicator) — the proportion of requests that are fast enough and correct enough — and the SLO is the threshold that indicator must stay above. A service level agreement (SLA) is the contractual, usually looser, version with financial consequences.
The reason SLOs matter in design discussions is the error budget: the difference between 100% and the objective. A 99.9% availability target over 28 days permits roughly 40 minutes of unavailability. That budget converts reliability from an argument into arithmetic — if the budget is intact you can ship faster and take risks, and if it is spent the response is to stop shipping features and fix reliability. It also stops the pursuit of nines that users cannot perceive and the business will not fund.
How it comes up in interviews
Bringing an SLO into a design answer unprompted signals production experience, particularly for infrastructure and site reliability roles. The strong move is to define the SLI precisely (which requests count, measured where — client or server) and then let the target drive the architecture: multi-region failover is justified by the objective, not by enthusiasm.
Example
A 99.9% monthly availability objective allows about 43 minutes of downtime; 99.99% allows about 4. The jump between those two numbers is usually the jump from single-region to multi-region, and it should be justified by the objective rather than assumed.
What separates a strong answer
Common answer
Reciting the SLI, SLO and SLA definitions correctly and stopping there.
What lands
Tying the number to a decision: "99.9% because the mobile client retries once, so a user only notices the second failure — and when the budget is half burnt by mid-month, the release train pauses."
Service Level Objective (SLO) interview questions
The forms this comes up in, and what a complete answer covers.
What is the difference between an SLI, an SLO and an SLA?
The SLI is the measurement — the proportion of requests that were successful and under the latency threshold. The SLO is the target you hold yourself to internally, say 99.9% over 28 days. The SLA is the promise made to a customer, with financial consequences attached, and it is deliberately looser than the SLO so that you breach your internal target and react before you breach the contract. If your SLA and SLO are the same number, you have no room to notice a problem.
How do you choose the target number?
Not by picking nines. Start from what the user actually notices, given retries and client behaviour, and from what your dependencies can support — your availability cannot meaningfully exceed the floor set by everything you call synchronously. Then check the cost: each additional nine typically multiplies engineering effort, and a target nobody will fund is worse than an honest lower one. A good sanity check is measuring current performance first and setting the SLO slightly above it.
What is an error budget and how does it change decisions?
The error budget is the inverse of the SLO — a 99.9% target over 28 days permits roughly 43 minutes of failure. That allowance becomes a resource: while budget remains, teams ship and take risks; when it is spent, the policy is to stop feature releases and spend the time on reliability. It turns reliability from an argument into arithmetic, and burn-rate alerts on the budget are usually better signals than raw threshold alerts because they page on customer impact rather than symptoms.
How would you set an SLO for a service that has never had one?
Pick one user-facing journey rather than trying to cover everything, and define an SLI you can actually compute from existing telemetry — usually good requests over valid requests at the edge, since server-side metrics miss failures that never reached you. Measure current performance for a few weeks, set the target near what you already achieve, publish it, and only then tighten. Setting an aspirational target on day one produces a permanently exhausted budget that everybody learns to ignore.