SLO vs SLA vs SLI
An SLI is a measured indicator of service health, an SLO is the internal target you set on that indicator, and an SLA is the external contract that promises a level of service and defines consequences if you miss it.
The three terms, precisely
These three acronyms form a hierarchy that is constantly confused. An SLI (Service Level Indicator) is a concrete measurement — for example, the percentage of HTTP requests that succeed, or the share served faster than 300 ms. It is just a number you compute from real traffic.
An SLO (Service Level Objective) is a target you set on an SLI, such as "99.9% of requests succeed over 30 days." It is internal, aspirational, and the thing your team actually engineers toward. An SLA (Service Level Agreement) is a formal contract with a customer that promises a level — often looser than your SLO — and attaches consequences like refunds or credits when breached. The clean mental model: SLIs measure, SLOs target, SLAs promise.
How the three fit together
Read them inside-out: an indicator is measured, an objective is set on that indicator, and an agreement is promised to a customer with the objective comfortably inside it.
SLI — the measurement
A Service Level Indicator is a ratio of good events to valid events: successful requests over total requests, or fast responses over all responses. It is observed, never negotiated.
SLO — the internal target
A Service Level Objective sets a threshold and window on an SLI — "99.95% availability over 28 days." It's what the team commits to engineer toward, and it drives prioritization decisions.
SLA — the external contract
A Service Level Agreement is a promise to a customer with teeth: miss it and you owe credits or refunds. It's typically set looser than your SLO so an internal miss doesn't immediately become a contractual breach.
The safety margin
Good practice keeps the SLO stricter than the SLA. If your SLA promises 99.9%, you might run an internal SLO of 99.95%, giving you warning room before a contract is at risk.
The error budget link
An SLO implies an error budget: 100% minus the objective. A 99.9% SLO permits 0.1% unreliability, and that budget governs how much risk you can take on releases.
Why the distinction matters
Confusing these terms leads to real mistakes. Teams that treat an SLA target as their engineering goal leave no margin for error, so every minor blip risks a contractual penalty. Teams that pick SLIs disconnected from user experience optimize numbers that don't reflect whether customers are actually happy.
Done right, the hierarchy gives you a shared language for reliability: SLIs tell you the truth, SLOs tell you whether the truth is good enough, and SLAs tell you what's at stake if it isn't. That alignment is the foundation of error-budget-driven engineering.
Measuring SLIs with AllStak
Setting an SLO is only useful if you can measure the underlying SLI. AllStak's uptime monitoring and request performance data give you the raw success rates and latency distributions that availability and latency SLIs are built from.
AllStak doesn't replace a formal SLA contract, but it gives you the observability to know — early — whether you're tracking toward your SLO or about to put an agreement at risk.
Related terms
SLO, SLA & SLI FAQ
What is the difference between an SLO and an SLA?
An SLO is your internal target on a metric, like 99.9% availability. An SLA is an external contract promising a service level to a customer, with consequences such as credits if you miss it. SLOs are usually stricter than SLAs.
What is an example of an SLI?
A common SLI is the percentage of successful HTTP requests over a period — say 99.95% of requests returned a non-error status. Latency SLIs (e.g. the share of requests faster than 300 ms) are also widely used.
Should an SLO be higher or lower than an SLA?
Your SLO should be stricter than your SLA so you have a buffer. If you breach your SLO internally you get an early warning, but you haven't yet broken a customer contract.
How do SLOs relate to error budgets?
An error budget is 100% minus your SLO. A 99.9% SLO gives you a 0.1% budget of allowable unreliability over the measurement window, which you can spend on risk like faster releases.
Explore more
Measure the SLIs behind your SLOs
AllStak gives you uptime and request-performance data to track availability and latency SLIs in one platform. Start free.