SLOs are internal reliability targets engineering teams set and measure themselves against, while SLAs are external, contractual promises made to customers, typically backed by financial penalties. Every SLA should be backed by one or more SLOs, but not every SLO becomes an SLA. The gap between an SLO and its corresponding SLA forms the error budget, the amount of unreliability a team can absorb before a breach becomes contractually costly. An example: a 99.9% SLA (43.2 minutes downtime/month) paired with a 99.95% SLO (21.6 minutes) leaves roughly a 21-minute buffer. AWS's EC2 uptime guarantees are cited as a real-world SLA example, and a Google Cloud engineer's definition is quoted for context.
Questions this post answers
What is the difference between an SLO and an SLA?
An SLO (Service Level Objective) is an internal reliability target an engineering team sets for itself, such as 99.9% of requests completing under 300ms. An SLA (Service Level Agreement) is an external, contractual promise made to a customer, usually backed by financial penalties like service credits or refunds if missed. Every SLA should be backed by at least one SLO, but not every SLO becomes a customer-facing SLA. Comparing reliability concepts like SLOs and SLAs gets easier with context daily.dev surfaces from the SRE community.
How do you calculate an error budget between an SLO and an SLA?
An error budget is the gap between your internal SLO and your external SLA. For example, an SLA promising 99.9% uptime allows 43.2 minutes of downtime per month, while an internal SLO of 99.95% allows only 21.6 minutes, leaving roughly a 21-minute buffer between breaching your own target and owing a customer money. Teams typically track this with burn-rate alerts rather than manual dashboard checks. Engineers tuning error-budget alerts can follow ongoing SRE practice discussions on daily.dev.
Why should an SLO be stricter than the SLA it backs?
An SLO is set tighter than the SLA so that internal warning signs appear before a customer-facing contractual breach occurs. Since an SLA carries financial and legal consequences, it is deliberately set looser than the SLO backing it, ensuring one bad day doesn't trigger a real payout while still giving engineering teams an early-warning system tied to their error budget. daily.dev helps engineers stay current on the reliability practices behind SLO and SLA design.