SLOs vs SLIs vs SLAs: A Practical Guide
Stop confusing these three things. This confusion is burning out your engineers.
The Problem
Most teams use these terms interchangeably. SLI, SLO, SLA. It all blurs together. So they pick the wrong targets. Then they chase impossible reliability numbers. Engineers work weekends. Team morale tanks. Nothing actually gets better.
Here's the thing: these three terms are completely different. Understanding the difference is the difference between a team that ships fast and a team that's always on fire.
Let's Use Ride-Sharing as an Example
You open the app. You request a ride. Three things matter:
The SLI: What You Actually Measure
SLI stands for Service Level Indicator. It's what you measure. For ride-sharing, the SLI is "time from ride request to driver arrival at pickup location."
That's it. You measure it. You write it down. You track it over time.
Other examples for ride-sharing:
- Successful ride completion (requested ride actually happens)
- App availability (can you even open the app)
- Payment success rate (transactions that go through)
- Driver acceptance time (how fast drivers respond)
You can measure anything. But pick the things that actually matter to your customers. If your app is up but takes forever to load, it feels broken. If payment fails half the time, customers leave. So pick SLIs that reflect real user experience.
The SLO: The Target You Promise Yourself
SLO stands for Service Level Objective. It's the target you set for your SLI. For ride-sharing, maybe it's "95% of ride requests get matched with a driver within 2 minutes."
Notice the number. 95%, not 100%. That's the key. SLOs are not about perfection. They're about what's realistic and sustainable.
For ride-sharing:
- "99.95% of payment transactions complete successfully"
- "99.9% app availability during peak hours"
- "97% of requested rides result in a completed trip"
This is the internal goal. You set it. Your team commits to it. It drives your engineering decisions.
The SLA: The Promise You Make to Customers
SLA stands for Service Level Agreement. It's a legal/contractual promise. "We promise that 95% of your ride requests will be matched within 5 minutes, or we credit your account."
Notice the stakes. SLAs have teeth. If you break them, you pay money.
For ride-sharing, that's "if we can't match you with a driver in 10 minutes, we give you a discount on your next ride."
An SLI is the thermometer. An SLO is the temperature you want to keep. An SLA is the promise you make to customers about that temperature, with financial consequences if you break it.
Why This Distinction Matters
If You Conflate Them, You Burn Out Your Team
Imagine a ride-sharing company that sets their internal SLO to "100% of ride requests matched within 1 minute." That's insane. No traffic, no edge cases, no nothing. It's humanly impossible.
Now imagine their SLA is "95% of ride requests matched within 5 minutes." The gap between what they promised themselves (100% in 1 minute) and what they promised customers (95% in 5 minutes) means engineers are always failing.
They work weekends trying to hit an impossible goal. They hire more engineers. They buy better servers. Nothing works because the goal is irrational. Team satisfaction tanks. Good engineers leave. Everything falls apart.
This is exactly what happens with software teams that don't understand the difference between SLOs and SLAs.
SLOs Are About Efficiency, Not Perfection
If you want 99.99% uptime (4 nines), you need to spend a LOT of money on redundancy, monitoring, automation, and on-call rotations. Your team will be constantly busy keeping the lights on.
If you want 99.5% uptime (less than 4 nines), you can actually ship features. You have time for both reliability and features.
The right SLO is the one where your team can spend 30% of their time on reliability work and 70% on shipping features. If it's the other way around, your SLO is too aggressive.
SLAs Are Business Decisions, Not Engineering Decisions
Your engineering team doesn't get to decide on SLAs. That's a business decision. Product, sales, and customers decide what SLA they want.
Your SLO should be slightly higher than your SLA to give you a safety buffer. If your SLA is 99.95%, your SLO should be 99.98% or higher. That buffer is your safety net. It means you have breathing room.
If your SLO equals your SLA, you're going to fail. There's no buffer. The moment you hit any issues, you're violating your customer commitment. Teams with this setup are always in crisis mode.
How to Actually Use SLIs and SLOs
Step 1: Pick 1 to 2 SLIs That Matter
Not 10. Not 20. One or two things that actually matter to your users.
For a web app: availability and latency. That's usually enough.
For an API: error rate and latency.
For a payment system: successful transaction rate and latency.
Ask your customers. "What breaks your day?" Usually the answer is simple.
Step 2: Look at Recent Performance and Set a Realistic SLO
Don't guess. Look at the last 3 months of actual performance. If you've been at 99.8% availability, your SLO should be 99.8%, not 99.99%.
Set a goal you can actually hit. Once you hit it consistently, you can tighten it. But start realistic.
Step 3: Alert on Error Budget Burn, Not Thresholds
This is the key insight. Instead of alerting on "P99 latency is over 200ms," alert on "we've burned 50% of our error budget this month and it's only day 15."
If your SLO is 99.95% monthly availability, you have a budget of 21 minutes of downtime per month. Each incident costs some of that budget. If you burn through it too fast, you need to slow down.
Here's the math:
This shift is powerful. Instead of chasing arbitrary latency numbers, you're watching budget. If you're burning budget too fast, you know you need to be more careful. If you're well under budget, you know you can take more risks and ship faster.
Common Mistakes
Mistake 1: SLOs That Are Too Aggressive
Chasing more nines without calculating the cost in engineering time. 99.99% uptime means you need automated failover, redundant everything, and basically a full-time on-call rotation. That costs money and happiness.
Most teams are better served by 99.5% or 99.9% SLOs with a team that's shipping fast and happy.
Mistake 2: SLAs That Don't Match Reality
You promised customers 99.95% but your actual SLO is 99.5%. You're going to break your SLA. Then you're paying penalties.
Your SLO needs to be higher than your SLA. Usually 0.5-1% higher to give you a buffer.
Mistake 3: Too Many SLIs
You measure latency, availability, error rate, cache hit rate, database query time, API response time, and 10 other things. Now you have alerts for all of them. Alert fatigue sets in. Important signals get ignored.
Pick 1 or 2 things your customers actually care about. Measure those. Ignore the noise.
Mistake 4: Ignoring Error Budget
You have a budget. You just don't know it. Error budget isn't theoretical. It's real. If your SLO is 99.95%, you get roughly 21 minutes of allowed errors/downtime per month. Once that budget is spent, you're violating your SLO.
Most teams never talk about this. So they accidentally violate their SLOs. Then they panic and rush to "fix reliability." But they never had a plan in the first place.
Why This Creates Productive Tension
The best teams understand SLOs create a healthy tension between shipping features and maintaining reliability.
If your error budget is healthy (say, you've only used 20% by day 15), you can take more risks. Ship that big refactor. Try that new database migration. The budget lets you.
But if you're burning budget fast (75% used by day 15), you need to be more careful. Hold off on risky changes. Focus on stability. Your error budget tells you when to accelerate and when to pump the brakes.
This is way better than arbitrary rules like "code freeze before releases" or "no deployments on Friday." Error budget gives engineers permission to move at the right speed for the situation.
The Takeaway
SLIs are what you measure. SLOs are what you target. SLAs are what you promise customers. These are three different things. Confusing them kills teams.
If your team understands the difference, you get:
- Realistic reliability goals that teams can actually hit
- Permission to ship features when budget allows
- Permission to slow down when budget is low
- Clear communication between engineering and business
- Happy engineers who aren't burning out
The teams that win are the ones that understand SLOs create productive tension between shipping and reliability. Too much reliability, no features. Too many features, your service is broken. The right SLO puts you in the middle, shipping fast and reliably.