SLO vs SLA vs SLI at a glance
| Term | What it defines or measures | Who owns it | Payment API example | If missed |
|---|---|---|---|---|
| SLO Service Level Objective | A reliability target for an SLI over a defined time window | Service owner, product, and SRE | At least 99.9% of valid payment requests succeed within 300 ms over a rolling 30-day window | The error budget is consumed; the team reviews risk and prioritizes reliability work |
| SLA Service Level Agreement | A customer-facing service commitment and its remedies | Business, legal, and the service owner | At least 99.5% of valid payment requests succeed within 300 ms each calendar month | The customer may qualify for service credits or another contractual remedy |
| SLI Service Level Indicator | Actual user-facing service performance calculated from telemetry | Platform, SRE, or engineering | 99.94% of valid payment requests succeeded within 300 ms | An SLI is measured, not breached; its value shows whether the SLO is being met |
SLO — Service Level Objective
An SLO is a target value or range for an SLI over a specified time window. It defines what good enough means for a service and gives the team an internal reliability objective rather than a contractual promise.
A complete SLO combines an indicator, a target, and a window—for example, at least 99.9% of valid requests succeed within 300 ms over a rolling 30-day window.
SLA — Service Level Agreement
An SLA is a customer-facing agreement that defines the expected service level and the remedy when the commitment is missed. Unlike an SLO, an SLA can carry financial or legal consequences.
Teams normally set the internal SLO more strictly than the external SLA so there is an operating buffer before a reliability miss becomes a contractual breach.
SLI — Service Level Indicator
An SLI is a quantitative measurement of a specific aspect of service performance. It is the observed value—not a target or a promise.
Useful SLIs describe user-visible outcomes such as request success rate, latency, or availability and define exactly which events count as good and valid.
How they work together
Start by choosing a user-visible measurement (SLI), set the internal target and time window (SLO), then make any external commitment and remedy explicit (SLA). Error budgets come from the SLO: the gap between 100% and the objective is the permitted unreliability. Use the SLO Calculator to translate a target into allowed downtime or failed requests, then the Error Budget Calculator to track consumption.
Common mistakes
Setting SLOs equal to SLAs. If your SLO equals your SLA, any SLO breach immediately triggers a contractual violation. Leave a buffer.
Too many SLIs. More SLIs mean more noise and more cognitive load. Most services need 2–4 SLIs that directly reflect user experience.
No consequences for SLO breaches. An SLO without a process for what happens when it breaches is just a number on a dashboard. Define the response before you need it.