SLIs and SLOs work together like measurement and target.
An SLI, Service Level Indicator, is the actual metric used to measure reliability.
An SLO, Service Level Objective, is the target or goal you want that metric to meet.
For example:
| Concept | Example |
| ------- | ------------------------------------------------- |
| SLI | Request success rate |
| SLO | 99.9% of requests should succeed over 30 days |
| SLI | API latency |
| SLO | 95% of API requests should complete within 300 ms |
| SLI | Availability |
| SLO | Service should be available 99.95% monthly |
So the SLI tells you what you are measuring, and the SLO tells you how good it needs to be.
How SLIs and SLOs complement each other
SLIs give the raw reliability signal. They answer questions like:
Is the service available?
Are requests successful?
Is latency acceptable?
Are users experiencing errors?
Is the system processing data correctly?
SLOs give those measurements business and operational meaning. They answer:
What level of reliability is acceptable?
When should we take action?
Are we meeting user expectations?
Can we release faster, or should we focus on stability?
Are we burning the error budget too quickly?
For example, saying “our API latency is 420 ms” is just an SLI value. It becomes meaningful only when compared to an SLO, such as “95% of requests should be under 300 ms.” Now the team can clearly see whether reliability is acceptable or not.
Why clear SLIs must come before meaningful SLOs
You cannot set a useful reliability target unless you first define the correct measurement.
A bad SLI creates a bad SLO.
For example, suppose you define availability using only server uptime. Your servers may be running, but users may still be getting failed checkout requests. In that case, the SLI is misleading. A better SLI would be something user-focused, such as:
Percentage of successful checkout requests
Percentage of successful login attempts
Percentage of API requests returning non-5xx responses
Percentage of page loads completed within an acceptable time
Once the SLI reflects real user experience, the SLO becomes meaningful.
Simple example
Imagine an e-commerce checkout service.
A weak SLI would be:
“The server is up.”
A better SLI would be:
“Percentage of checkout requests completed successfully.”
Then a meaningful SLO could be:
“99.5% of checkout requests should complete successfully over a rolling 30-day window.”
That SLO now reflects what users actually care about: whether they can buy something successfully.
Why this matters in SRE
Clear SLIs and SLOs help teams make better engineering decisions.
They help with:
Prioritizing reliability work
Reducing meaningless alerts
Defining error budgets
Balancing feature speed and system stability
Measuring real user experience
Improving incident response
Creating shared expectations between engineering and business teams
Without clear SLIs, SLOs become random numbers. Teams may set goals like “99.99% uptime” without knowing what is actually being measured, whether it matters to users, or whether the target is realistic.
In short
SLIs measure reliability. SLOs define the reliability goal.
A clear SLI must come first because it defines the truth you are measuring. Once that measurement is accurate and user-focused, the SLO becomes a meaningful target for reliability, alerting, error budgets, and engineering priorities.