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

> An SLI is what you measure (e.g., percent of successful requests), an SLO is the internal target you set for it (99.9%), and an SLA is the external contract with consequences if you miss it.

Source: https://openobserve.ai/glossary/slo-sla-sli/
Published: 2026-07-08
Term: SLO vs SLA vs SLI
Category: SRE & Incident Response
Related terms: what-is-error-budget, four-golden-signals, mttr-vs-mttd

---

**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](/glossary/what-is-error-budget/), which turns reliability from an absolute ("never break") into a spendable resource that funds release velocity. See [how to set meaningful SLOs](/blog/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](/blog/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](/metrics/) and [traces](/traces/) you already ship, and its [alerting](/alerts/) supports burn-rate style alerts on those SLIs - so reliability targets are monitored where the telemetry lives.