SLI vs SLO vs SLA: how do they relate?

WHAT THIS TESTS This question checks whether you fluently use the vocabulary that all SRE reliability work is built on, and whether you understand how the three concepts chain together to drive decisions rather than being three names for the same thing.

A GOOD ANSWER COVERS Start with the SLI: a carefully defined quantitative measurement of some aspect of service quality, for example the proportion of valid requests served successfully, or the fraction of requests faster than a threshold. Then the SLO: an internal target value or range for an SLI over a window, such as 99.9 percent availability over twenty-eight days; it is the line that defines acceptable reliability and powers the error budget. Then the SLA: an explicit agreement with customers that includes consequences, like refunds or credits, when reliability falls below a stated bound. Crucially, the SLO should be tighter than the SLA, giving an internal safety margin so the team reacts before contractual penalties trigger.

COMMON WRONG ANSWERS Using SLI, SLO, and SLA interchangeably. Saying every service needs an SLA; many internal services have only SLOs. Setting the SLO equal to or looser than the SLA, which removes the early-warning buffer.

LIKELY FOLLOW-UPS How does an SLO relate to an error budget? How do you choose a good SLI? Why not just aim for 100 percent? Who owns the SLA versus the SLO?

ONE CONCRETE EXAMPLE A payments API measures the SLI success rate equals good responses over total valid requests. The team sets an SLO of 99.95 percent monthly. The customer contract, the SLA, promises 99.9 percent with service credits below that. Because the SLO is stricter, when monthly success dips to 99.92 percent the error budget alerts fire and engineering freezes risky launches, all while the SLA remains intact and no credits are owed.