What is SLA vs SLO vs SLI?
In our tour of Cloud Monitoring, we learned how to track the "Vital Signs" of a system. But how do you know if a 98% success rate is "good enough"? How do you decide when to stop building new features and start fixing bugs?
In the world of Site Reliability Engineering (SRE), we use three acronyms to turn gut feelings into mathematical facts: SLI, SLO, and SLA.
These three terms represent a hierarchy of promises. You start with a metric (SLI), turn it into a target for your team (SLO), and finally turn it into a legal contract for your customers (SLA).
The Analogy:
Think of a Pizza Delivery Service.
SLI (The Stopwatch): This is the actual time it took to deliver the pizza. "It took 28 minutes."
SLO (The Team Goal): This is the internal goal for the shop. "We want 95% of our pizzas to be delivered in under 30 minutes."
SLA (The Legal Promise): This is the public guarantee. "30 minutes or it’s free!"
"What is the actual measurement?"
An SLI is a specific metric that tells you how your service is performing right now. It is usually expressed as a percentage:
Example: "99.5% of homepage requests returned a 200 OK status code over the last hour."
"What do we want the measurement to be?"
This is the "Line in the Sand." It is an internal target that your engineering team agrees to meet to keep customers happy.
Example: "We will maintain a 99.9% success rate for the login service over a rolling 30-day window."
The 2026 Secret: Your SLO should always be stricter than your SLA. This gives you a "buffer" to fix problems before they cost the company money.
"What happens if we fail to meet the SLO?"
This is a legal contract between a service provider and a customer. It defines the consequences (usually money or service credits) if the service is unreliable.
Example: "If uptime drops below 99.0%, we will refund 10% of your monthly bill."
| Feature | SLI | SLO | SLA |
| Focus | Measurement | Target | Consequences |
| Audience | Engineers | Engineers / Product Owners | Customers / Lawyers |
| Purpose | To track health. | To guide development speed. | To define business liability. |
| Frequency | Real-time. | Monthly/Quarterly. | Quarterly/Yearly. |
The most powerful thing about an SLO is that it creates an Error Budget.
If your SLO is 99.9%, you have a 0.1% "budget" for failure.
If you have plenty of budget left: Your team can move fast, take risks, and deploy new features.
If you have "spent" your budget (too many outages): You stop all new feature work and focus 100% on stability until the budget recovers.
This ends the "War" between Developers (who want to move fast) and Operations (who want stability). The budget decides who wins.
In the cloud, "100% Uptime" is an impossible (and expensive) myth. By using SLI/SLO/SLA, you admit that things will fail. You choose exactly how much failure is acceptable before it hurts the business. This allows you to spend your money and time where it actually matters.
SLIs are the data.
SLOs are the goals that keep your team disciplined.
SLAs are the promises that keep your customers trusting you.