Every engineering team says reliability matters. Far fewer can answer a simple question: how reliable does this service actually need to be? Without a clear answer, teams either chase 100% uptime and slow down every release, or ship fast and find out about reliability problems from angry customers.
Service Level Indicators (SLIs), Service Level Objectives (SLOs) and error budgets give you a shared, measurable answer. They come from Site Reliability Engineering, but any DevOps team can use them. This guide explains each concept in plain language, shows how they fit together, and walks through setting your first SLO.
SLI, SLO and SLA: The Three Terms Explained
Service Level Indicator (SLI)
An SLI is a measurement of how your service is behaving from the user's point of view. It is usually expressed as a ratio of good events to total events. For example: the percentage of HTTP requests that returned successfully, or the percentage of requests served in under 300 milliseconds.
Service Level Objective (SLO)
An SLO is the target you set for an SLI over a period of time. For example: 99.9% of requests will succeed over a rolling 30-day window. The SLO is an internal goal that the engineering team commits to.
Service Level Agreement (SLA)
An SLA is a contract with customers that includes consequences, such as service credits or refunds, if a promised level of service is not met. SLAs are business and legal documents. Your SLO should always be stricter than your SLA, so that you notice and fix problems before you break a promise to customers.
A simple way to remember the difference: the SLI is what you measure, the SLO is what you aim for, and the SLA is what you promise (and pay for if you miss).
What Is an Error Budget?
An error budget is the amount of unreliability your SLO allows. If your SLO is 99.9% success over 30 days, then 0.1% of requests are allowed to fail. That 0.1% is your error budget.
Converted to time, a 99.9% availability target allows roughly 43 minutes of downtime in a 30-day month. A 99.99% target allows only about 4 minutes and 20 seconds. A 99% target allows about 7 hours and 12 minutes. Each extra "nine" costs much more engineering effort, which is why choosing the right number matters.
The idea behind error budgets is that 100% reliability is the wrong goal. Users cannot tell the difference between 99.99% and 100% when their own Wi-Fi or mobile network is less reliable than that. Spending effort to get there means fewer features and slower delivery. The error budget turns reliability into a resource that the team can spend on purpose.
Why SLOs and Error Budgets Matter for DevOps
- They end the speed versus stability argument. If there is budget left, the team can ship features and take reasonable risks. If the budget is spent, the focus moves to reliability work. The data decides, not opinions.
- They focus on users. SLIs measure what users experience, not internal signals like CPU usage.
- They reduce noisy alerts. You alert when the error budget is being consumed too fast, not on every small spike.
- They create a shared language between developers, operations, product managers and leadership.
This approach is a core part of the SRE role. If you are unsure how SRE differs from DevOps, read SRE vs DevOps vs Platform Engineering.
Choosing Good SLIs
The best SLIs are close to the user experience and easy to understand. Common categories include:
- Availability: the proportion of requests that succeed (for example, not returning a server error).
- Latency: the proportion of requests faster than a threshold, such as 95% of requests under 300 milliseconds.
- Quality or correctness: the proportion of responses that return complete, correct data rather than degraded results.
- Freshness: for data pipelines, the proportion of data updated within an expected time.
- Throughput or durability: for batch and storage systems, the proportion of jobs completed or data retained.
Measure SLIs as close to the user as you reasonably can. Load balancer logs are often a better source than application logs, because they also capture requests that failed before reaching your code. For user-facing products, real user monitoring and synthetic checks add another view.
Most teams collect these metrics with tools covered in our guide to observability, often using Prometheus for metrics and Grafana for dashboards.
How to Set Your First SLO: Step by Step
Step 1: Pick a critical user journey
Start with something that matters to users and the business, such as logging in, searching products, or completing a checkout. Do not try to cover every service at once.
Step 2: Choose one or two SLIs for that journey
For checkout, sensible SLIs might be the percentage of checkout requests that succeed and the percentage completed in under one second.
Step 3: Look at historical data
Check how the service has performed over the last few weeks or months. If you currently achieve 99.7% success, setting a 99.99% target on day one only guarantees failure. Start near current performance and tighten it over time if users need more.
Step 4: Choose the time window
A rolling 28- or 30-day window is common. It smooths out short spikes but still reacts to sustained problems.
Step 5: Agree on an error budget policy
Write down what happens when the budget runs low or runs out. Typical policies include pausing risky feature releases, prioritising reliability fixes, or requiring extra review for changes until the budget recovers. The policy only works if product and engineering leadership both sign it.
Step 6: Review and adjust
Review SLOs every quarter. If users are unhappy even though you meet the SLO, the target or the SLI is wrong. If you always have most of your budget left, you may be over-investing in reliability and could move faster.
Alerting on Error Budget Burn Rate
Burn rate measures how fast you are using your error budget compared to the expected pace. A burn rate of 1 means you will use exactly the whole budget by the end of the window. A burn rate of 10 means you will use it ten times faster, which needs attention now.
A popular approach is multi-window, multi-burn-rate alerting:
- Fast burn: page the on-call engineer if, for example, 2% of the monthly budget is consumed in one hour.
- Slow burn: open a ticket if, for example, 10% of the budget is consumed over three days.
This catches serious outages quickly while ignoring short blips that do not threaten the objective. It is one of the most effective ways to reduce noise, and works well alongside the techniques in how to set up Prometheus alerts without alert fatigue.
SLOs and Other DevOps Metrics
SLOs describe reliability from the user's side. DORA metrics such as deployment frequency, lead time for changes, change failure rate and time to restore service describe how well your delivery process works. Together they show whether you are delivering quickly and safely. Learn more in DevOps metrics that actually matter.
Common SLO Mistakes
- Too many SLOs. Start with a few that matter. Dozens of SLOs nobody reads add no value.
- Targets set by wishful thinking. A target of 99.999% without the architecture to support it creates frustration, not reliability.
- Measuring the wrong thing. CPU, memory and disk are useful for debugging, but they are not SLIs because users do not experience them directly.
- No error budget policy. Without agreed consequences, an SLO is just a dashboard.
- Never revisiting targets. User expectations and systems change, so your SLOs should too.
Tools for Managing SLOs
You can build SLOs with Prometheus recording rules and Grafana dashboards. Open-source projects such as Sloth and Pyrra generate the recording and alerting rules for you. Commercial observability platforms including Datadog, New Relic, Dynatrace and Google Cloud's operations suite include built-in SLO tracking. Explore more options in our list of top cloud monitoring and observability tools.
Conclusion
SLIs tell you how users experience your service, SLOs set a realistic target, and error budgets turn that target into a practical tool for deciding when to ship and when to stabilise. Start with one critical journey, base your target on real data, agree on a budget policy, and refine it over time. If you want to build a career around this discipline, read how to become a Site Reliability Engineer.
