SLI — Service Level Indicator
An SLI is a quantitative measurement of a specific aspect of service performance. It is the thing you actually measure — the raw number that tells you how your service is behaving right now.
Common SLIs include: request success rate (percentage of requests returning a non-5xx response), request latency (p50, p95, p99 response time), availability (percentage of time the service responds to health checks), and throughput (requests per second).
An SLI is just a measurement. It has no target attached — it is simply a fact about current system behavior.
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 your service. An SLO is an internal engineering commitment — it is not a contractual promise to customers.
Example: "99.9% of requests will return a 2xx response within 500ms, measured over a rolling 30-day window." This combines an SLI (request success rate within 500ms) with a target (99.9%) and a time window (30 days).
SLOs should be set at the level users find acceptable — not the maximum you can achieve. Setting an SLO too high wastes engineering resources; setting it too low trains users to expect unreliable service.
SLA — Service Level Agreement
An SLA is a contractual agreement between a service provider and a customer that defines the expected level of service and the consequences if that level is not met. SLAs typically include financial penalties (service credits) for violations.
Because SLAs carry financial and legal consequences, they are typically set more conservatively than SLOs — often 1–2 percentage points below the internal target. If your SLO is 99.9%, your SLA might commit to 99.5%.
| Term | What it is | Who sets it | Consequence of breach |
|---|---|---|---|
| SLI | A measurement | Engineering | None — it's just data |
| SLO | An internal target | Engineering + Product | Internal reliability review |
| SLA | A contract | Business + Legal | Financial penalties / credits |
How they work together
The three terms form a hierarchy. You start by deciding what to measure (SLI), then set an internal target for that measurement (SLO), and finally make external promises based on that target (SLA). Error budgets are derived from SLOs — the gap between 100% and your SLO target is the budget you have to spend on unreliability.
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.