SLA is a promise. SLO is a target. SLI is a measurement.
Every reliable engineering team uses all three, but confuses them constantly. This guide explains what each one is, how they connect, how to calculate them with real formulas, and how error budgets turn them into actual engineering decisions. We include a practical framework for setting SLOs, the mistakes teams make most often, and 10 FAQs targeting the exact queries people search for this topic. For the broader context on why SLOs matter more in modern SRE, see Traditional SRE vs Modern SRE.
43.2 min
Downtime allowed at 99.9%
your monthly error budget
1 − SLO
The error budget formula
the unreliability you can spend
2–3
SLOs per service
more than five dilutes focus
99.7%
Realistic composite SLO
eroded by every dependency
The Short Answer
Three definitions, one sentence each:
SLA (Service Level Agreement): The external promise you make to customers, usually backed by financial or legal consequences if you break it.
SLO (Service Level Objective): The internal target your team commits to hitting.
SLI (Service Level Indicator): A measurement of how the service is actually behaving right now.
How the three fit together
Measures it
The live number from your monitoring
Targets it
The internal goal, stricter than the SLA
Promises it
The external promise, with consequences
The SLI measures it, the SLO targets it, the SLA promises it. Your SLO always sits stricter than your SLA.
Or, even simpler: an SLA is what you promised your customers. An SLO is what you promised yourself. An SLI is what your monitoring tells you.
The three work together in one direction. Your SLA sets the outer bound. Your SLO is stricter than your SLA. Your SLI tells you whether you're hitting it. Get any one wrong and the whole system falls apart.
SLA vs SLO vs SLI: The Comparison Table
| Dimension | SLA (Agreement) | SLO (Objective) | SLI (Indicator) |
|---|---|---|---|
| What it is | A promise | A target | A measurement |
| Audience | External customers | Internal team | Internal team |
| Enforcement | Legal or financial consequences | Operational consequences (feature freeze, prioritization) | None, it's a metric |
| Typical example | 99.9% uptime with service credits if missed | 99.95% availability over 30 days | HTTP success rate: 99.94% |
| How often it changes | Rarely, tied to contracts | Quarterly to yearly | Every minute |
| Who owns it | Customer success, legal, sales | SREs, engineering leaders | SREs, platform engineers |
| Source of truth | Contracts | Reliability program docs | Observability tools |
The most important line: your SLO must be stricter than your SLA. Your internal target has to be tougher than your customer promise, or the safety buffer disappears the first time something goes wrong.
What Is an SLA?
An SLA is the formal commitment you make to your customers, backed by a contract with financial or legal consequences if you don't meet it.
SLAs are what get negotiated in enterprise sales. When AWS commits to 99.99% availability for EC2, that's an SLA. When they miss it, service credits kick in on a tiered structure. Look at AWS's actual SLA page and you'll see the pattern: three tiers of service credits (10%, 25%, 100% of monthly bill) depending on how bad the miss was.
SLAs have four properties that make them different from SLOs:
They are external. Written for customers, not internal engineering teams.
They are legally enforceable. Breach one and you owe money or credits.
They are conservative. SLAs are usually looser than the SLO because you need buffer.
They are hard to change. SLOs can evolve every quarter. An SLA is renegotiated at contract time.
A common mistake: writing an SLA before you have historical data proving you can hit it. If your service has been running at 99.5% for the last six months, don't commit to 99.9% in your SLA. Commit to what you've actually demonstrated, plus a small buffer downward.
What Is an SLO?
An SLO is the internal target you commit to hitting on a specific metric over a specific time window.
The syntax is always the same: metric + target + window. For example: "The checkout success rate will be at least 99.95% measured over any rolling 30-day window."
Every part of that sentence matters.
- •The metric defines what you're measuring
- •The target defines what good enough looks like
- •The window defines the time period you evaluate against
Google Cloud's SRE guidance recommends starting SLOs slightly below what you currently achieve. If your service is running at 99.94% availability today, don't set your SLO at 99.99%. That's setting yourself up to fail every quarter. Set it at 99.9% and tighten from demonstrated baselines.
The most important rule: your SLO must be stricter than your SLA. If your SLA promises customers 99.9% availability, your internal SLO should be 99.95% or 99.99%. That gap is your safety buffer. Without it, you have no margin between we're doing okay internally and we've broken our customer contract.
Modern SRE teams also limit how many SLOs they track. The SRE Handbook 2026 guidance recommends two to three SLOs per service: one for availability, one for latency, and optionally one for a business metric. More than five dilutes focus and makes incident triage harder.
What Is an SLI?
An SLI is a quantitative measurement of how your service is behaving from the user's perspective. Not the CPU on your database. Not memory pressure on your Kubernetes pods. Those are internal indicators. An SLI has to reflect what the user actually experiences.
The classic definition from the Google SRE Book: an SLI is a "carefully defined quantitative measure of some aspect of the level of service that is provided." In practice, an SLI is usually a ratio of good events to total valid events, expressed as a percentage from 0 to 100.
The four most common SLI categories:
The percentage of successful requests over total requests. If your service handles 1 million requests in a day and 500 of them return 5xx errors, your availability SLI is 99.95%.
The percentage of requests served within a defined time threshold. Not average latency. Percentiles. p95, p99, and p99.9. Averages hide tail latency. If your average response time is 200ms but your p99 is 3 seconds, one in every hundred users is having a bad time. For a good breakdown of why percentiles matter, see Honeycomb on latency measurement.
Requests handled per second, often relevant when systems have capacity limits.
The percentage of responses that returned correct data. This is harder to measure but critical for AI systems, search engines, and recommendation services.
An SLI is only useful if it correlates with what users care about. If your database CPU is at 40% but customers can't complete checkout, the CPU number is not an SLI. The checkout success rate is.
Error Budgets: What Turns an SLO Into Action
An SLO by itself is a number on a dashboard. Error budgets are what make that number actionable.
An error budget is the acceptable amount of unreliability permitted by your SLO over a given window.
Formula: Error Budget = 1 - SLO Target
Example: an SLO of 99.9% availability over 30 days gives you 0.1% of 43,200 minutes, which is 43.2 minutes of allowed downtime per month.
That 43.2 minutes is not a target. It's not a stretch goal. It is a hard ceiling.
The concept only works if you pair it with an error budget policy. A policy defines what happens as the budget gets consumed. A common tiered structure:
- •Above 75% remaining: Ship features normally
- •25 to 75% remaining: Deploy cautiously, prioritize reliability work
- •Below 25% remaining: Feature freeze, reliability work only
- •0% remaining: Emergency fixes only, engineering leadership notified
Error budget policy at a glance
75–100%
Ship features normally
25–75%
Deploy cautiously
0–25%
Feature freeze
0%
Emergency only
As the budget burns down, the rules tighten automatically. No debate needed.
The policy removes politics. When a product manager asks why can't we ship this feature?, the answer is not a debate. It's the policy. For the full playbook on setting one up, see Google's SRE Workbook on error budget policies.
A Practical Framework for Setting SLOs (5 Steps)
Most SRE guides tell you what SLOs are but skip the part where you actually pick numbers. Here is a framework that works in production.
Step 1: Identify the user journey, not the service. Users don't care about your services. They care about tasks. Complete checkout is a journey. Payment service uptime is a service metric. Start with the journey.
Step 2: Pick two to three SLIs that reflect that journey. For checkout: success rate (availability), p99 latency, and completion rate (quality). Not fifteen metrics. Three at most.
Step 3: Look at your last 90 days of data. What did the service actually do? If checkout succeeded 99.94% of the time over 90 days, that's your baseline.
Step 4: Set the SLO slightly below the baseline. Baseline was 99.94%. Set the SLO at 99.9%. That gives you room to improve without setting yourself up to fail.
Step 5: Write the error budget policy before you need it. Define the tiers now, while nobody's in an incident. Once the budget is burning, it's too late to negotiate the rules.
Ship it. Then revisit every quarter and tighten as the service improves. If you want to see how enterprise teams structure this at scale, the Nobl9 SLO Handbook is a solid reference.
The Composite SLO Problem
If your service depends on other services, your SLO has to account for their SLOs. This is where a lot of teams get tripped up.
Example: your web application depends on a database, a CDN, and a DNS provider. Each has its own SLO:
- •Web application: 99.9%
- •Database: 99.95%
- •CDN: 99.9%
- •DNS: 99.95%
Your effective (composite) SLO is calculated by multiplying them:
0.999 × 0.9995 × 0.999 × 0.9995 = 0.9970
Your realistic composite SLO is roughly 99.7%, not 99.9%. Every dependency erodes your ceiling. If you commit to 99.9% in an SLA without doing this math, you'll miss your own target every quarter and never understand why.
This is one of the most common mistakes in enterprise reliability programs. Your ceiling is set by your weakest dependency, not by your own service's performance.
The 5 Most Common Mistakes
Ranked by how often they show up in real production incidents.
Confusing SLA with SLO in engineering discussions. The team says our SLA is 99.9% when they mean their SLO. Then when an incident hits and the SLO is breached, they panic because they think they've broken a customer contract. Two different things. Different consequences.
Setting SLOs based on aspiration, not data. We want 99.99% because that's what the big companies have. If your service is running at 99.5%, an SLO of 99.99% is fiction. Start from baseline. Tighten over time.
Measuring the wrong SLI. Tracking database CPU as your reliability metric. Tracking average latency instead of p99. The SLI has to reflect user experience. If it doesn't, your SLO is a lie.
No error budget policy. The SLO exists. The dashboard shows the budget. Nobody knows what to do when it burns. So they ignore it and ship features anyway. The SLO becomes theater.
Forgetting composite SLOs. Committing to 99.9% availability when your dependencies mathematically can't support it. The service will miss target every quarter and nobody will understand why.
How Modern SRE Teams Actually Use SLOs
The classic Site Reliability Engineering book from O'Reilly describes SLOs as monthly review artifacts. That's not how good teams use them anymore.
Modern SRE teams treat SLOs as live inputs to engineering decisions. When error budget burn rate spikes, alerts fire. When the budget hits 50%, deploys automatically require more scrutiny. When it hits 25%, feature velocity slows without a debate.
This automation is the difference between we have SLOs and our SLOs actually shape how we work. Teams doing it well have:
- •Real-time budget burn rate calculations, not monthly reviews
- •Alerting tied to burn rate, not just current values
- •Deploy pipelines that check budget before allowing changes
- •Automated incident detection when a critical SLO is at risk
- •AI SRE tooling that correlates budget burn to specific incidents and changes
The Netflix Tech Blog has written extensively on burn-rate alerting and multi-window multi-burn-rate policies, which are worth studying as you mature your SLO program. For a deeper look at how modern reliability programs work, see Four Golden Signals of SRE and What Is SRE Toil? How to Measure and Reduce It.
Key Takeaways
- •SLA is a promise. SLO is a target. SLI is a measurement. If you remember one line from this piece, make it that one.
- •SLO must be stricter than SLA. The gap is your safety buffer.
- •Error budgets make SLOs actionable. Without a policy, an SLO is just a dashboard.
- •Start from baseline, not aspiration. Set SLOs slightly below what your service already does.
- •Two to three SLOs per service. More than five dilutes focus.
- •Do the composite math. Your ceiling is set by your weakest dependency, not your own service.
- •Measure from the user's perspective. Database CPU is not an SLI. User-visible success rate is.
Frequently Asked Questions
An SLA is an external contract with customers with legal consequences; an SLO is an internal target you set stricter than the SLA to build safety buffer.
An SLO is the target you're trying to hit; an SLI is the actual measurement of whether you're hitting it.
Technically yes, but you lose the early warning system that gives you time to react before the SLA breaks.
Set your SLO slightly below your current 90-day baseline, then tighten quarterly as reliability improves.
Error budget equals 1 minus the SLO target; a 99.9% SLO over 30 days gives you 43.2 minutes of allowed downtime per month.
A pre-agreed set of actions triggered as the budget is consumed, like feature freeze below 25% remaining, that removes politics from reliability decisions.
The effective SLO of a service that depends on other services, calculated by multiplying all dependency SLOs together.
Two to three per service is the sweet spot: one for availability, one for latency, and optionally one business metric.
99.9% availability gives you 43.2 minutes of allowed downtime per month, which fits most consumer services but is loose for critical infrastructure.
Alert on burn rate, not absolute value, so you catch fast-burning incidents before the budget is exhausted.
Further Reading
The Four Golden Signals of SRE
Latency, traffic, errors, and saturation, the metrics that feed your SLIs.
Traditional SRE vs Modern SRE
Why SLOs matter more in modern reliability programs.
What Is SRE Toil?
How to measure and reduce the manual work that eats engineering time.
Root Cause Analysis for Production Incidents
The methods that still work in production, and how AI changes them.
Never Miss What's Breaking in Prod
Breaking Prod is a weekly newsletter for SRE and DevOps engineers.
Subscribe on LinkedIn →