SRE
SLO vs SLA
Short answer
An SLI is what you measure. An SLO is the target you hold yourself to. An SLA is a contract with consequences if you miss it — and it should always be looser than your SLO.
In simple terms
Three words that get used interchangeably and mean quite different things. The indicator is a number you actually measure: the proportion of requests served successfully in under 300ms, say. The objective is the target for that number, chosen by you. The agreement is a promise to somebody else, usually with money attached.
The relationship that matters is the ordering. Your SLO should be stricter than your SLA, and the gap between them is your margin for error. If you promise customers 99.9% and internally target 99.9%, then the moment you miss your own target you have already breached a contract. Target 99.95% internally and you get a warning before it costs anything.
The reason to bother with any of this is not measurement for its own sake. It converts “how reliable should we be” — which is an argument — into “how much unavailability may we spend”, which is a budget engineers and product owners can share.
What actually happens
The error budget is the inverse of the objective, expressed as allowed failure over a window. A 99.9% objective over 30 days permits about 43 minutes of unavailability. That is a quantity, and quantities can be spent, tracked and argued about factually.
Burn rate is how fast you are spending it relative to the window. Consuming 50% of the budget in 10% of the window is a burn rate of five, and it is the more useful alert: it fires while there is still budget left, rather than after it is gone.
The choice of window changes the meaning. A rolling 30-day window smooths out a single bad day; a calendar month resets and can hide a problem that straddles the boundary. Neither is wrong, but the two disagree, and teams that do not decide end up arguing about the number instead of the reliability.
What a target actually permits
Objective Allowed unavailability per 30 days 99% 7 hours 12 minutes 99.5% 3 hours 36 minutes 99.9% 43 minutes 99.95% 21 minutes 99.99% 4 minutes 19 seconds
Worth reading twice before promising four nines. Four minutes across a whole month has to cover every deploy, every dependency wobble and every certificate renewal — and it is less time than most on-call engineers take to wake up and open a laptop.
◑ The mistake this causes
Setting the objective to 100%, or as close as sounds impressive.
Why people do it Nobody wants to write down that some failure is acceptable. But an objective of 100% has an error budget of zero, which means every change is a violation and the framework stops being able to inform any decision.
What you see The SLO is quoted in planning documents and never referenced during an actual incident, because everybody knows it is aspirational. A number nobody believes is worse than no number, since it also discredits the next one you set.
How it shows up in production
The useful version looks like this. A team has spent 80% of its monthly error budget in the first week. That is not an alert about a specific failure — it is a signal that the current rate of change is unsustainable.
The conversation it enables is the point: freeze non-essential releases and spend the time on reliability until the window rolls over. That is a decision the budget makes uncontroversial, because it is a fact about a shared number rather than an opinion about whether the service feels flaky.
How to tell which one you are hitting
- Is it a number you measure, a target, or a promise?
- Measured is the SLI. A target you chose is the SLO. Something with a customer and a consequence is the SLA.
- Is your SLO stricter than your SLA?
- It should be. If they are equal you have no warning margin, and the first time you miss your internal target you are already in breach.
How this gets asked in an interviewpreparation
Usually phrased as “Explain SLI, SLO and SLA.”
What a strong answer contains Define all three in one breath and then explain the ordering and why it exists. Bringing up error budgets and burn rate unprompted moves the answer from vocabulary to how reliability work actually gets prioritised.
The follow-up “What would you do if you had spent 80% of the budget in the first week?” The answer they are listening for involves slowing change, not working harder.
What comes next
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere