Skip to main content
An SLI (service level indicator) is a measurement of service behavior, such as the percentage of requests served successfully. An SLO (service level objective) is the internal target you set for that measurement, such as 99.9% success over 30 days. An SLA (service level agreement) is the external contract that promises customers a level of service, with penalties if you miss it. SLIs feed SLOs, and SLOs are set stricter than SLAs.

​
Comparison at a glance

​
What is an SLI?

An SLI is a quantitative measure of some aspect of service level — nothing more. Common SLIs include availability (successful requests ÷ total requests), latency (proportion of requests faster than a threshold), and freshness or durability for data systems. A good SLI is expressed as a ratio of good events to total events, because that maps directly to user experience. “CPU utilization” is a metric; “percentage of checkout requests completing under 500 ms” is an SLI.

​
What is an SLO?

An SLO attaches a target and a window to an SLI: “99.9% of checkout requests complete successfully, measured over a rolling 30 days.” SLOs are internal commitments. Their real power is the error budget they imply — at 99.9% over 30 days, you can “spend” about 43 minutes of full downtime before breaching. While budget remains, teams ship freely; when it’s exhausted, reliability work takes priority. That trade-off is the core mechanism SRE teams use to balance velocity against stability.

​
What is an SLA?

An SLA is a business agreement with customers, typically written by legal and sales rather than engineers. It specifies a service level (often looser than your SLO) and what happens when you miss it: service credits, refunds, or termination rights. Because breaching an SLA costs real money and trust, teams deliberately keep SLOs tighter than SLAs — the SLO acts as an early-warning line you cross internally before customers are affected contractually.

​
Why should your SLO be stricter than your SLA?

The gap between them is your safety margin. If your SLA promises 99.5% monthly uptime and your SLO targets 99.9%, an SLO breach triggers internal escalation while you still have roughly 3.2 hours of budget before the contractual line. Setting SLO equal to SLA means every internal miss is instantly a customer-facing breach, with no room to react.

​
Worked example

A B2B API team defines the stack like this:
  • SLI: proportion of API requests returning a non-5xx response within 300 ms.
  • SLO: 99.9% over a rolling 30-day window — an error budget of about 43 minutes.
  • SLA: 99.5% monthly, with a 10% service credit for any month below it.
Mid-month, a bad migration causes 25 minutes of elevated errors. The SLI dips, consuming more than half the error budget. The SLO isn’t breached yet, but the team freezes risky deploys for the rest of the window and prioritizes the migration fix. The SLA (which allows roughly 3.6 hours of downtime per month) is never in danger — which is exactly the point. The SLO absorbed the incident so the SLA didn’t have to.

​
Do you need all three?

You always need SLIs and SLOs if you want to manage reliability deliberately — they cost nothing contractually and give teams a shared target. SLAs only make sense when customers demand contractual guarantees, which is common for paid B2B products and rare for internal services. Internal platform teams often run SLIs and SLOs alone, sometimes informally calling the SLO an “internal SLA.” In Rootly, incidents affecting SLO-backed services can be tracked against severity and service impact from creation onward. See Incident Management.