What are SLIs, SLOs and SLAs, and how do error budgets work?

These terms are often conflated. An SLI is a number you measure, such as the fraction of requests served successfully in under 300 milliseconds. An SLO is the target you choose for that SLI over a window, such as 99.9 percent over 28 days. An SLA is a legal or commercial agreement with a customer, usually looser than the SLO and carrying credits or penalties.

Choosing a good SLI

• Measure what users experience, ideally at the edge or client
• Define the population precisely: which requests, regions and time window
• Use a ratio of good events to valid events rather than an average latency
• Keep the number of SLIs small and tied to a user journey
• Include freshness or correctness where staleness is the real failure

An error budget is one minus the SLO. At 99.9 percent over 28 days, the budget is about 40 minutes of full unavailability, or an equivalent number of failed requests. It turns reliability into a shared resource: the team can spend it on risky launches, and when it is exhausted, feature work pauses in favor of reliability.

Alert on burn rate, not on a single threshold. A fast burn over a short window catches a severe outage, while a slow burn over days catches a gradual leak. Multi-window alerts reduce noise. A 2 percent budget burn in one hour is much more urgent than the same burn spread over a month.