SRE · commonly confused
SLO vs SLA
Short answer
Reproduced on Python 3.9.6, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.
First published
On this page · 10 sections
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, with consequences attached, such as a refund or a penalty.
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.
Words used on this page
- SLI
- Service level indicator: a number you measure that reflects the service users get, such as the share of requests that succeed.
- SLO
- Service level objective: the target you set for an SLI, such as 99.95% of requests succeeding over four weeks.
- SLA
- Service level agreement: a contract with users that says what happens if the SLOs in it are missed, such as a refund.
- nines
- Shorthand for availability targets: three nines is 99.9%, four nines 99.99%. Each extra nine allows ten times less failure.
- error budget
- The failure an SLO allows: 100% minus the target, over the window. For 99.9% it is 0.1% of the time or of the requests.
- burn rate
- How fast the budget is being spent compared with the pace that would use it up exactly at the end of the window. A burn rate of 1 is on schedule; 5 runs out after a fifth of the window.
- rolling window
- A window that moves with today, such as the last four weeks. A bad day counts for the whole window, then drops out.
- calendar window
- A fixed period such as a month or a quarter. It resets at the start of each period, which suits planning and contracts.
- error budget policy
- A written agreement on what a team does when the budget is spent, for example pausing feature releases.
What actually happens
The error budget is the complement of the objective (100% minus the SLO), expressed as allowed failure over a window. A 99.9% objective over 30 days permits about 43 minutes of complete unavailability. If the SLO counts requests rather than minutes, as Google's do, the budget is 0.1% of requests, and an outage at a quiet hour spends less of it than one at peak. 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 window keeps a bad day in the number for the whole window, which matches how users remember it; a calendar month resets on the first, which suits business planning but splits a problem that straddles the boundary. Google's workbook suggests four weeks rather than 30 days, so every window holds the same number of weekends. 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 12 seconds 99.95% 21 minutes 36 seconds 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. It is also less than the 5 minutes Google's SRE book gives as a typical response time for a page on a user-facing service.
Try it yourself
Before you start
- The SLA text, if there is one: its percentage, its window, how it defines downtime or a failed request, and what happens on a miss. Your SLO has to be measured the same way to be comparable.
- An SLI you can compute from your monitoring, such as successful requests divided by all requests, and an agreed window: rolling or calendar, and how long.
- Python 3 or a calculator for the arithmetic below; it was reproduced on Python 3.9.6.
- Agreement with whoever decides releases on what happens when the budget runs low, written down as an error budget policy before you need it.
From an SLA and an SLO to minutes and a burn rate
Reproduced on Python 3.9.6 on macOS, with the time zone set to UTC; it is plain arithmetic, so any Python 3 prints the same. The example service promises customers 99.9% over 30 days in its SLA and targets 99.95% internally. Both figures are made up for the example.
Command
python3 -c 'print(round(30 * 24 * 60 * (100 - 99.9) / 100, 1))' python3 -c 'print(round(30 * 24 * 60 * (100 - 99.95) / 100, 1))' python3 -c 'print(round(0.50 / 0.10, 1))'
Output
$ python3 -c 'print(round(30 * 24 * 60 * (100 - 99.9) / 100, 1))' 43.2 $ python3 -c 'print(round(30 * 24 * 60 * (100 - 99.95) / 100, 1))' 21.6 $ python3 -c 'print(round(0.50 / 0.10, 1))' 5.0
How to read it
- The SLA's 99.9% over 30 days allows 43.2 minutes: 30 × 24 × 60 minutes times the 0.1% that may fail. The table on this page rounds it down to 43.
- The internal 99.95% allows 21.6 minutes. When you miss the SLO there are still about 21.6 minutes left before the contract is breached. That gap is the safety margin Google's SRE book advises keeping.
- Minutes assume an SLO measured in time, or a complete outage. If your SLI counts requests, read the same numbers as shares of requests, 0.1% and 0.05% that may fail; then an outage at a busy hour spends more budget than one at a quiet hour.
- Spending 50% of the budget in the first 10% of the window is a burn rate of 5.0: five times the pace that would use it up exactly at the end. Kept up, it empties the budget a fifth of the way in, on day six of thirty.
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 any failure at all 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.
If it goes wrong
- Your SLO report shows 99.95% and a customer says you missed a 99.9% SLA
- You are not measuring the same thing. Compare the SLA's definition of downtime, its window and where it is measured with your SLI. Google's SRE book notes there must be an objective way to measure the SLOs in an agreement, "or disagreements will arise". Keep one SLI that matches the contract exactly.
- The availability number jumps on the first of the month
- That is a calendar window resetting. Decide which window each report uses and label it. Google's workbook finds a four-week rolling window a good general-purpose interval, with weekly and quarterly summaries for prioritising and planning.
- The SLO is met every month and users still complain
- The SLI measures something users do not care about, or measures it in the wrong place. Google's SRE book says to start from what users care about, not what you can measure, and that some problems only show up when you measure at the client.
- The budget is spent and nobody agrees what happens next
- Write an error budget policy before the next miss: what changes, who decides, and who settles disagreements. Google's workbook publishes an example with exactly those sections, including escalation to the CTO.
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: whether to slow non-essential releases and spend the time on reliability. What happens at 80% is up to the team's error budget policy; Google's example policy halts changes other than P0 and security fixes once the budget is exceeded, until the service is back within its SLO. 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.
Security considerations
- Keep security fixes out of any freeze. Google's example error budget policy halts "all changes and releases other than P0 issues or security fixes". A policy that also blocks security patches when the budget is spent trades a reliability number for exposure.
- Make load tests and penetration tests identifiable in your SLI data. Google's example policy treats budget spent by "users out of scope for the SLO (e.g., load tests or penetration testers)" differently, which only works if that traffic can be told apart; otherwise an authorised test shows up as an outage in the SLA report.
- Protect the SLI pipeline like any other control. Whoever can edit the recording rules or reclassify errors can change the reported number without changing reliability, and the example policy lists miscategorized errors as something the team must fix. Keep SLI definitions in version control with review.
- Keep the raw measurements behind SLA reports. Google's SRE book notes that a real SLA violation might trigger a court case for breach of contract, so the data is evidence: store it with access control, and for as long as the contract allows claims.
In an interview
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.
Sources
The behaviour this page describes, as documented by the projects themselves.
Terms used here (1)plain definitions
Short definitions for the vocabulary on this page, in case any of it is new. Each links to the full entry.
- SLA/SLO/SLI
- Service Level Agreement, Objective, and Indicator — a hierarchy of reliability metrics. SLIs measure specific aspects of service performance, SLOs set target values for those indicators, and SLAs are contractual commitments with consequences for violations.
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere
Something wrong or out of date? Report it