SLO vs SLA vs SLI: What's the Difference?

SLI, SLO, and SLA form the vocabulary of reliability engineering, and the relationship is simple: the SLI is the measurement, the SLO is your target for that measurement, and the SLA is the contract you sign about it.

SLI: Service Level Indicator — what you measure

An SLI is a quantitative measure of some aspect of service quality, almost always expressed as a ratio: good events / total events. Examples: the fraction of requests served successfully, served under 300ms, or of queue messages processed within 60 seconds. Good SLIs measure what users experience — availability at the edge, not CPU on a host.

SLO: Service Level Objective — the target

An SLO sets a target for an SLI over a window: “99.9% of requests succeed, measured over 28 days.” SLOs are internal engineering commitments. Their power is the flip side: the allowed 0.1% of failure is your error budget, which turns reliability from an absolute (“never break”) into a spendable resource that funds release velocity. See how to set meaningful SLOs.

SLA: Service Level Agreement — the contract

An SLA is an SLO with legal and financial consequences, promised to customers: miss 99.9% uptime, issue service credits. Because breaching an SLA costs money and trust, internal SLOs should always be stricter than external SLAs — your own alarm fires before the contractual one.

How they work together

SLI  →  measured:   99.94% of requests succeeded
SLO  →  target:     99.9%   (internal, drives alerting & error budget)
SLA  →  contract:   99.5%   (external, with penalties)

The operational payoff is SLO-based alerting: instead of paging on CPU spikes, you page when the error-budget burn rate threatens the SLO — fewer, more meaningful alerts tied directly to user impact.

SLOs in OpenObserve

OpenObserve computes SLIs from the metrics and traces you already ship, and its alerting supports burn-rate style alerts on those SLIs — so reliability targets are monitored where the telemetry lives.

Frequently asked questions

Can you have an SLO without an SLA?

Yes, and most SLOs are exactly that - internal reliability targets with no contract attached. The reverse is dangerous - an SLA without underlying SLOs means you've made promises you aren't measuring. Internal SLOs should always be stricter than any external SLA so you breach your own target first.

What is a good SLO target?

The one your users actually need - not the most nines you can afford. 99.9% (about 43 minutes of downtime per month) suits most business applications; each additional nine roughly 10x-es the engineering cost. Setting SLOs tighter than user requirements burns engineering effort and forbids healthy release velocity.

What is an example of an SLI?

The proportion of HTTP requests that return successfully in under 300ms, measured at the load balancer over a rolling 28-day window. Good SLIs are ratios of good events to total events, measured as close to the user as practical.