What are SLIs, SLOs, and SLAs, and how do they relate to each other in site reliability engineering?

Question

Accepted Answer

SLIs, SLOs, and SLAs form a hierarchy that connects technical measurements to business commitments. Understanding this hierarchy is fundamental to SRE because it provides the framework for making reliability decisions based on data rather than gut feeling.

A Service Level Indicator (SLI) is a quantitative measurement of some aspect of the service that users care about. It is the raw data point. Common SLIs include request latency (how long a request takes to complete), availability (the proportion of requests that succeed), throughput (the number of requests the system can handle), and error rate (the proportion of requests that fail). SLIs should directly reflect user experience. If users do not notice or care about a metric, it is probably not a good SLI.

A Service Level Objective (SLO) is a target value or range for an SLI. It is the internal goal your team commits to maintaining. For example, if your SLI is request latency, your SLO might be "99% of requests complete in under 200 milliseconds measured over a 30-day rolling window." SLOs are set by the engineering team based on what users expect and what is technically and economically feasible. They are not customer-facing commitments but internal targets that guide engineering priorities.

A Service Level Agreement (SLA) is a formal contract between a service provider and its customers that includes consequences (usually financial) for not meeting the agreed-upon service levels. An SLA might state "the service will be available 99.9% of the time per month, and if availability falls below this, the customer receives a 10% credit on their bill." SLAs are typically less strict than SLOs because you want an internal buffer. If your SLA promises 99.9% availability, your SLO should target 99.95% or higher so you catch problems before they breach the contractual commitment.

The relationship flows from bottom to top: SLIs measure reality, SLOs set internal targets against those measurements, and SLAs make external promises based on confidence in meeting SLOs. Not every service needs an SLA (internal services often do not), but every service should have SLIs and SLOs.

A practical example: for an e-commerce checkout service, the SLI is the success rate of checkout requests. The SLO is 99.95% of checkout requests succeed over a 30-day window. The SLA with enterprise customers promises 99.9% checkout availability with financial penalties for breaches. The gap between the SLO and SLA gives the team a buffer to detect and fix issues before they become contractual violations.