Your service is running, the metrics are green, and yet users complain. Or the opposite: an alert fires at 3 a.m. for a problem nobody noticed. This gap between what you measure and what your users experience is the symptom of a fundamental problem: you are not measuring the right things.
This page explains how SLIs, SLOs and error budgets answer this problem, for teams that run a service in production and want to arbitrate between velocity and stability without subjective debate. You will find the definition of each term, the method to calculate an error budget, and the multiwindow alerting technique (burn rate) recommended by Google to detect incidents without drowning the on-call team in false positives.
What you will learn
This page will help you:
- Distinguish SLI, SLO and SLA and know at which level each decision sits.
- Choose a relevant SLI among the four families (availability, latency, freshness, correctness).
- Calculate an error budget and the cost of each incident against it.
- Configure multiwindow burn rate alerts that limit false positives.
- Document an error budget policy the team can apply.
- Tool the follow-up with generators such as OpenSLO or Sloth rather than spreadsheets.
The problem: measuring what really matters
Why technical metrics are not enough
Most teams monitor infrastructure metrics: CPU, memory, disk space, server response time. These metrics are useful for diagnosis, but they do not answer the essential question: are my users satisfied?
A server can show 20 % CPU and 2 GB of free RAM while serving slow pages because of a badly optimised SQL query. Conversely, a CPU spike at 95 % during a nightly batch affects nobody if no user is connected.
The difference between "the system works" and "users are satisfied" is at the heart of the SRE (Site Reliability Engineering) approach. This is why Google developed a precise vocabulary to talk about reliability: SLIs, SLOs, SLAs and error budgets. If these basics are missing, the Introduction to SRE lesson sets the context before this page.
The SLI, SLO, SLA hierarchy
These three terms are often confused. Here is how they relate:
| Term | Meaning | Question it answers | Example |
|---|---|---|---|
| SLI | Service Level Indicator | What do we measure? | Percentage of successful requests |
| SLO | Service Level Objective | What level do we aim for? | 99.9 % success over 30 days |
| SLA | Service Level Agreement | What consequences if we fail? | 10 % credit below 99.5 % |
The SLI is the raw metric. The SLO is the internal objective. The SLA is the external contractual commitment. They form a pyramid where each level depends on the previous one: without a reliable SLI, no credible SLO; without an SLO that holds, no SLA you can honour.
SLI: measuring the user experience
What is a good SLI?
An SLI (Service Level Indicator) is a quantitative metric that measures one aspect of service quality as perceived by the user. The word "perceived" is crucial: an SLI does not measure what your infrastructure does, but what your user experiences.
Google recommends expressing SLIs as a ratio:
SLI = (number of "good" events) / (total number of events)This formula has several advantages. The result is always between 0 % and 100 %, which makes it easy to understand and compare. It fits naturally with the calculation of the error budget. And it lets you use the same analysis tools for every SLI.
The four types of SLI
Depending on the type of system, different SLIs are relevant:
Definition: the proportion of requests that end with a valid response.
Formula: successful requests / total requests
What counts as "successful": a request that returns an HTTP 2xx or 4xx code (client errors are not service failures). 5xx codes count as failures.
When to use it: for any service that answers user requests. It is the most universal SLI.
Concrete example: out of 1 million requests, 999,500 succeeded. Availability SLI = 99.95 %.
Definition: the proportion of requests served below an acceptable time threshold.
Formula: requests < threshold / total requests
Why not an average: the average hides extreme cases. If 95 % of your requests answer in 50 ms but 5 % take 10 seconds, the average will be about 550 ms, which looks acceptable while 5 % of your users have a disastrous experience.
Multiple thresholds: it is common to define several latency SLIs: "90 % of requests under 100 ms" and "99 % under 400 ms".
Concrete example: out of 1 million requests, 950,000 answered in under 200 ms. Latency SLI (200 ms) = 95 %.
Definition: the proportion of data served that is up to date according to a defined threshold.
Formula: up-to-date data / total data served
When to use it: for data pipelines, caches, reporting systems. Any situation where users consult data that may be stale.
Concrete example: a dashboard displays metrics. Out of 10,000 displays, 9,800 show data less than 5 minutes old. Freshness SLI (5 min) = 98 %.
Definition: the proportion of responses that are correct.
Formula: correct responses / total responses
Difficulty: defining "correct" is not always obvious. For a search engine, does the right result appear in the top 10? The top 3? In first position?
When to use it: calculation systems, recommendation engines, data transformation pipelines.
Concrete example: a billing system processes 100,000 transactions. 99,950 are calculated correctly. Correctness SLI = 99.95 %.
Where to measure SLIs
Where you take the measurement affects its precision, and therefore the trust you can place in the figure displayed.
| Measurement point | Advantages | Drawbacks |
|---|---|---|
| Server logs | Easy to set up | Does not see requests that never reach the server |
| Load balancer | Closer to the user | Does not capture client network problems |
| Client instrumentation | Measures the real experience | Complex to implement, incomplete data |
| Synthetic monitoring | Reproducible, controlled | Does not represent real traffic |
Good practices for SLIs
Few but relevant: 2 to 5 SLIs per service are enough. Too many SLIs dilute attention and complicate decisions.
User-centred: each SLI must answer the question "did the user get what they wanted?". If an SLI does not reflect the user experience, it has no place.
Continuously measurable: an SLI you can only calculate once a week is useless to drive daily decisions.
Standardised: use the same definitions and aggregations for all your services. It eases comparison and tooling.
SLO: defining reliability objectives
What is an SLO?
An SLO (Service Level Objective) is a target value for an SLI over a given period. It answers the question: "What level of reliability is enough for our users?"
An SLO has three elements:
| Element | Description | Example |
|---|---|---|
| SLI | The measured metric | Availability (successful requests / total) |
| Target | The aimed percentage | 99.9 % |
| Window | The measurement period | 30 rolling days |
The full statement becomes: "99.9 % of requests must succeed over a 30-day rolling window."
Why 100% is not a good objective
It is tempting to aim for 100 % availability. It is a mistake for three reasons.
It is technically impossible. Even the best-designed systems suffer outages. Failing hardware, human errors, natural disasters, software bugs: unavailability is inevitable.
It is economically irrational. Going from 99 % to 99.9 % is expensive. Going from 99.9 % to 99.99 % is much more expensive. Going from 99.99 % to 99.999 % is astronomically expensive. At some point, the investment is no longer worth the marginal benefit.
It is imperceptible to the user. Between 99.99 % and 99.999 %, the user cannot tell the difference. Their own WiFi network, mobile carrier and browser introduce more instability than your service.
Choosing the right measurement window
The measurement window shapes the behaviour of the SLO, and therefore how quickly an old incident "leaves" the calculation.
Rolling window (recommended): "the last 30 days". Closer to the user experience: a major incident on the last day of the month does not "disappear" the next day.
Calendar window: "this month". It aligns with business cycles and reporting, but can create perverse behaviours (taking risks at the start of the period, freezing everything at the end).
Google recommends a 4-week rolling window (28 days). It always contains the same number of weekends, which avoids variations caused by weekly traffic patterns. The examples on this page use 30 days, a round figure that is easier to calculate.
SLO by type of service
The right SLO level depends on the business context, not on a universal standard to copy and paste.
| Type of service | Typical SLO | Justification |
|---|---|---|
| Payments, authentication | 99.99 % or more | Immediate loss of trust if unavailable |
| Consumer application | 99.9 % | Velocity/stability balance |
| Internal tool | 99.5 % | Captive users, more tolerant |
| Prototype / MVP | 99 % | Velocity comes before stability |
Error budget: the objective arbiter
What is an error budget?
The error budget is the amount of unavailability tolerated by the SLO. It is the gap between 100 % and your objective.
Error Budget = 100% - SLOWith a 99.9 % SLO over 30 days:
- Error budget = 0.1 %
- In time: 30 days x 24 h x 60 min x 0.1 % = 43.2 minutes
- In requests (with 1 million requests per month): 1,000 requests can fail
The error budget as a decision tool
The error budget turns a subjective tension (Dev wants to ship, Ops wants stability) into an objective decision mechanism.
-
Budget available: innovation allowed
As long as there is error budget left, the team can deploy features, experiment and take calculated risks. Errors are normal and expected.
-
Budget consumed: focus on stability
When the error budget is exhausted, non-critical deployments are paused. The team focuses on fixing problems, improving tests and eliminating toil (repetitive manual work that wears reliability down without adding value).
-
Budget rebuilt: back to normal
As time passes without incidents, the budget rebuilds (rolling window). The team can resume deployments.
Error budget policies
An error budget without an enforcement policy is useless. Document clearly what happens when the budget is exhausted.
Common actions:
- Freeze of feature deployments (bug fixes allowed)
- Prioritisation of reliability tickets
- Mandatory post-incident review
- Engineering time dedicated to automation
Who decides:
- The product owner can request an exception for a critical deployment
- The SRE/Ops team has the power to refuse
- An escalation to management settles conflicts
Calculating error budget consumption
For each incident, you can calculate its "cost" as a percentage of the error budget:
Incident cost = (errors caused / total budget) x 100Example: a 99.9 % SLO over 1 million requests per month
- Budget = 1,000 requests can fail
- The incident causes 300 errors
- Cost = 300/1,000 x 100 = 30 % of the monthly budget
This metric helps you prioritise: the incidents that consume the most budget deserve the most attention in postmortems.
Alerting on consumption: multiwindow burn rate
Knowing how much error budget is left is not enough: you must also be alerted before it runs out. The burn rate measures how fast you consume your budget compared with a "normal" pace that would exhaust the budget exactly at the end of the window.
A burn rate of 1 means you consume the budget at the planned pace, exactly enough to last the whole window. A burn rate of 14.4 means you would exhaust the monthly budget in about 2 days if the pace continued: it is the signal of an ongoing incident that deserves to wake up on-call immediately.
The trap of a single-threshold alert is the impossible trade-off between reactivity and noise: a low threshold fires too many false positives on small spikes, a high threshold misses slow but real degradations. Google SRE recommends combining two time windows (a long one and a short one) that must exceed the threshold at the same time to fire the alert. This combines the sensitivity of the short window with the robustness of the long window against isolated spikes.
| Severity | Long window | Short window | Burn rate | Budget consumed |
|---|---|---|---|---|
| Page (wakes up on-call) | 1 hour | 5 minutes | 14.4 | 2 % |
| Page (wakes up on-call) | 6 hours | 30 minutes | 6 | 5 % |
| Ticket | 3 days | 6 hours | 1 | 10 % |
This table reproduces the reference parameters published in Google's SRE Workbook for a 99.9 % SLO: the first two rows wake up on-call, the third opens a ticket, because slow consumption over three days leaves time to act during working hours. The burn rates (14.4, 6, 1) do not depend on the SLO target: they express a share of the budget consumed over a window, for a 30-day period. Only the matching error-rate threshold changes, it equals the burn rate × (1 − SLO). For 14.4: 14.4 × 0.001 = 1.44 % errors with a 99.9 % SLO, but 0.144 % with 99.99 %. These alerts usually end up in the same channel as your on-call rotation, the short window serving to confirm the incident is still active before waking someone up.
Tooling SLOs: OpenSLO and Prometheus generators
Writing by hand the PromQL queries that calculate the burn rate for each service, each window and each threshold quickly becomes unmanageable beyond a few services. Two open source approaches avoid this debt.
OpenSLO is a vendor-neutral YAML specification: it describes an SLO (SLI, target, window) in a declarative format independent of the underlying monitoring tool, which lets you version your reliability objectives as code and share them between teams.
Sloth is a generator that takes a simplified SLO definition and automatically produces the matching Prometheus rules (recording rules and multiwindow alerts), including partial support for the OpenSLO format. The main benefit is avoiding manual calculation errors in burn rate thresholds and guaranteeing uniform rules across all the services of an organisation.
SLA: the contractual commitment
SLA vs SLO
The SLA (Service Level Agreement) is a contract with your users. It includes consequences (usually financial) if it is not met.
| Aspect | SLO | SLA |
|---|---|---|
| Nature | Internal objective | External commitment |
| Audience | Technical team | Customers, contracts |
| Consequences | Work prioritisation | Penalties, credits |
| Level | Stricter | More permissive |
A well-designed SLA is less strict than the internal SLO. If your SLO is 99.9 % and your SLA 99.5 %, you have a margin to react before having to compensate your customers.
A typical SLA example
The SLA turns the observed availability into a graduated financial consequence: the more severe the outage, the higher the credit granted to the customer. This scale protects the customer from a prolonged degradation without penalising the provider for a one-off minor incident.
| Monthly availability | Credit |
|---|---|
| 99.5 % or more | None |
| 99.0 % - 99.5 % | 10 % |
| 95.0 % - 99.0 % | 25 % |
| Below 95.0 % | 50 % |
Setting up SLIs/SLOs: a pragmatic method
The six steps below start from the user and end with the review of the objectives. They follow each other in order: an SLO set before measuring the service's baseline is almost always wrong.
-
Identify the critical user journeys
Before defining metrics, understand what your users are trying to accomplish. What are the main actions? Which ones are critical for your business? Which ones cause the most frustration when they fail?
-
Define 2 to 5 SLIs per service
For each critical journey, identify the important dimensions: did the action succeed (availability)? Was it fast (latency)? Was the result correct or up to date (correctness/freshness)?
-
Set realistic SLOs
Start by measuring your current performance for a few weeks. Your first SLO can sit slightly below this baseline: ambitious enough to be meaningful, realistic enough to be achievable.
-
Automate the follow-up
Set up a dashboard that shows in real time the current SLIs, the remaining error budget and the trend. Configure multiwindow burn rate alerts for when the budget is consumed too fast.
-
Document the error budget policy
Write down in black and white what happens when the budget is exhausted, who has the power to decide on exceptions, and how to escalate conflicts.
-
Iterate
The first SLOs will not be perfect. Review them every quarter: does the SLO match real user satisfaction? Were incidents missed? Is the level too strict or too lax?
Common pitfalls
This table sums up the most frequent mistakes observed when a team starts with SLOs, so you do not reproduce them one by one through trial and error.
| Pitfall | Problem | Solution |
|---|---|---|
| 100 % SLO | Impossible to hold, blocks any risk-taking | Accept that some level of error is normal |
| Too many SLIs | Dilutes attention, complicates decisions | 2-5 SLIs max per service |
| Technical SLIs | CPU, RAM do not reflect the user experience | Measure what the user perceives |
| No policy | The error budget becomes a number with no consequence | Document the actions when the budget is exhausted |
| Overambitious SLO | Team in permanent failure, demotivation | Start conservative, tighten progressively |
| Single-threshold alert | Too many false positives or missed slow incidents | Multiwindow alert (short + long burn rate) |
Key points
-
SLIs measure the user experience
Not the infrastructure, not technical metrics. What the user perceives: it works, it is fast, it is correct.
-
SLOs define "reliable enough"
100 % is neither possible nor desirable. The right SLO satisfies your users without blocking innovation.
-
The error budget arbitrates decisions
Budget available: you can take risks. Budget exhausted: you stabilise. No more subjective discussions.
-
The burn rate fires the alert at the right time
A multiwindow alert (short + long) detects fast incidents without drowning on-call in the false positives of single-threshold alerts.
-
SLAs are contractual commitments
Always keep a margin between SLO and SLA. SRE aims for the SLO to avoid triggering the SLA.
-
Tooling avoids calculation errors
Generators such as Sloth or specifications such as OpenSLO standardise alerting rules rather than rewriting them by hand for each service.
-
Start simple, iterate
Your first SLOs will not be perfect. Measure, learn, adjust.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Incidents and postmortems: handling the crisis, learning without blame
A new full quiz with random questions
Work again only on the questions you missed
External resources
Google's SRE Book and SRE Workbook remain the founding references on SLOs and error budgets: they detail implementation cases and burn rate formulas that go beyond the teaching scope of this page.
- Implementing SLOs (Google SRE Workbook), detailed guide with concrete examples
- Service Level Objectives (Google SRE Book), the founding chapter on SLOs
- Alerting on SLOs (Google SRE Workbook), the reference for multiwindow burn rate thresholds
- The Art of SLOs (Google), practical resources for implementation
FAQ: frequently asked questions
The questions below cover the most frequent doubts about SLOs: the difference with the SLA, calculating the error budget, the burn rate and what happens when the budget is exhausted.