An SLO (Service Level Objective) is the internal reliability target your engineering team sets and measures itself against, for example: “99.9% of requests complete in under 300ms.” An SLA (Service Level Agreement) is the external, contractual promise you make to a customer, usually backed by financial penalties if you miss it. Every SLA should be backed by one or more SLOs. Not every SLO needs to become an SLA.
| SLO | SLA | |
|---|---|---|
| What it is | Internal reliability target | External, contractual commitment |
| Who sets it | Engineering/SRE team | Sales, legal, or account management (negotiated with the customer) |
| Who it’s for | Internal, drives engineering decisions | External, the customer or contracting party |
| Consequence of missing it | Error-budget burn: triggers a freeze, postmortem, or re-prioritization | Financial: service credits, refunds, or contract penalties |
| How strict it should be | Tighter than the SLA (needs a buffer) | Looser than the SLO backing it |
| Example | ”99.95% of checkout requests succeed in under 500ms, over 28 days" | "99.9% monthly uptime, or the customer gets a 10% service credit” |
What is an SLO?
An SLO is a specific, measurable target, expressed as [metric] [comparison] [target] over [time window]. For example: “99.9% of API requests return successfully within 300ms, measured over a rolling 28 days.” It’s built on an SLI (Service Level Indicator), the actual measured data (latency, error rate, availability) that tells you whether you’re hitting the target. Teams use SLOs to make real trade-off calls: ship the risky feature this sprint, or spend it paying down reliability debt. For the full three-way breakdown with more examples, see our SLA vs SLO vs SLI guide.
What is an SLA?
An SLA is a contract, usually between a vendor and a customer, stating a guaranteed level of service and the remedy if it isn’t met. SLAs almost always carry a consequence: a service credit, a discount, or in rare cases termination rights. Because an SLA carries financial and legal weight, it’s set looser than the SLO backing it, so one bad day doesn’t trigger a real payout. AWS, for example, guarantees 99.99% monthly uptime for EC2 in a multi-AZ Region, dropping to 99.5% for a single instance, with credits scaled to how far availability fell short.
The key difference
The gap isn’t reliability level: it’s who the promise is for and what breaking it costs. An SLO is a promise your team makes to itself; missing it costs engineering time. An SLA is a promise your company makes to a customer; missing it costs money or trust. That’s why SLOs are set stricter than SLAs: they’re the early-warning system meant to catch a problem before it burns through the SLA and becomes a billable failure.
“An SLA normally involves a promise to a service user that the service availability SLO should meet a certain level over a certain period. Failing to do so then results in some kind of penalty.”
Adrian Hilton, Customer Reliability Engineer, Google Cloud. From SRE fundamentals: SLI vs SLO vs SLA, Google Cloud Blog.
How SLOs and SLAs work together: the error budget
The gap between your SLO and your SLA is your error budget: how much unreliability you’re allowed to “spend” before it turns contractually painful. If your SLA promises 99.9% uptime (43.2 minutes of downtime per month) and your internal SLO targets 99.95% (21.6 minutes), you have roughly a 21-minute buffer between “we breached our own target” and “we owe the customer money.” Most teams track that buffer with burn-rate alerts rather than checking dashboards by hand, since the whole point of an error budget is catching the burn early enough to still act on it.
The bottom line
An SLO is the target you hold yourself to. An SLA is the promise you make to someone else, backed by a penalty if you break it. Set the SLO tighter than the SLA, watch the gap between them as your error budget, and the SLA mostly takes care of itself.
If you’re setting these up for the first time, our practical guide to implementing SLOs walks through picking the right SLIs and setting realistic targets. And once they’re live, Last9’s alerting can watch your error-budget burn rate in production and flag it while there’s still time to act, not just after the SLA’s already been missed.
FAQ
Is an SLO the same as an SLA?
No. An SLO is an internal engineering target; an SLA is an external contract with a customer. An SLA is usually backed by one or more SLOs, but the reverse isn’t true. Most SLOs never become customer-facing SLAs.
What’s the difference between SLO, SLA, and SLI?
An SLI is the raw measurement (for example, “99.92% of requests succeeded last month”). An SLO is the target you set for that measurement (for example, “99.9% or better”). An SLA is the contractual consequence if you miss it. See our full SLI vs SLO vs SLA breakdown for worked examples.
Who’s responsible for SLOs vs SLAs?
SLOs are typically owned by engineering or SRE teams as an internal operating target. SLAs are usually negotiated by sales, legal, or account management, since they’re a customer-facing contract term, though SRE input is essential to make sure the SLA is actually achievable.
What happens if you miss an SLO vs an SLA?
Missing an SLO triggers an internal process: an alert, a postmortem, or a decision to pause feature work for reliability (this is “burning your error budget”). Missing an SLA triggers a contractual remedy, most often a service credit or refund, occasionally a right for the customer to exit.
Can you have an SLA without an SLO?
Technically yes, but it’s a bad idea: you’d be making a contractual promise with no internal target or measurement to know if you’re on track to keep it. Every well-run SLA is backed by at least one SLO, set stricter than the SLA itself.
