An SLI is what you measure, an SLO is what you aim for, and an SLA is what you promise. The SLI (service level indicator) is a number from monitoring, like the percentage of successful requests. The SLO (service level objective) is your internal target for that number, say 99.95%. The SLA (service level agreement) is the contractual promise to the customer, usually set looser than the SLO, with a refund attached if you miss it. The order is fixed: you measure the SLI, aim at the SLO, and promise the SLA.
These three get swapped around constantly, and the confusion is not harmless. Promise an SLA you have no SLI to measure, and you cannot prove you met it. Set an SLO equal to your SLA, and you have left yourself no room to react before the promise breaks. Getting the relationship right is what turns "we have good uptime" into something you can actually run a business on.
The three, defined
| Term | Stands for | What it is | Example |
|---|---|---|---|
| SLI | Service Level Indicator | A measured number about the service | 99.982% of checks succeeded this month |
| SLO | Service Level Objective | Your internal target for the SLI | Keep availability at or above 99.95% |
| SLA | Service Level Agreement | The promise to the customer, with a penalty | 99.9% or a service credit is owed |
The nesting matters. The SLI feeds the SLO, and the SLO sits stricter than the SLA. If your SLA is 99.9%, a sensible SLO is 99.95%, and the SLI is the live availability figure telling you where you actually are against both.
SLI is the number you measure
An SLI is a ratio of good events to total events, expressed as a percentage. For uptime, the usual SLI is the share of checks (or requests) that succeeded. For an API you might track the share of responses that returned the right payload within a latency threshold, not just the share that returned anything at all. The SLI is only as good as the measurement behind it, which is why it has to come from checks that run from outside your network, on an interval short enough to catch the outages that matter. That measurement is what SLA monitoring produces.
Pick SLIs that reflect the user's experience, not the server's mood. "CPU was under 80%" is a metric, but it is not an SLI, because a user does not care about your CPU. "The checkout page loaded correctly within two seconds" is an SLI, because that is the thing the user actually needed to happen.
SLO is the target you run against
The SLO is the line you hold internally. It is the number your alerting and your on-call decisions are built around, and it should be tighter than anything you have promised a customer. The gap between your SLO and 100% is your error budget: the amount of failure you have decided is acceptable in the window. When you are burning through that budget faster than the window can absorb, that is the signal to stop shipping risky changes and stabilize.
Set the SLO stricter than the SLA on purpose. If you promise customers 99.9% but run your own alerting at 99.95%, you start reacting to trouble with budget still on the clock, rather than after the contractual promise is already broken. The same objective-and-indicator discipline is spreading beyond uptime into watching the freshness and reliability of data pipelines, where a stale table is the outage.
alertping
Turn checks into an SLI you can trust
AlertPing measures the success rate of 30-second checks across two regions and publishes it as a rolling percentage, giving you the indicator your SLO and SLA both depend on.
SLA is the promise with teeth
The SLA is the external, contractual version. It states the availability level you guarantee, the window it is measured over, what counts as downtime, what is excluded (usually scheduled maintenance), and the consequence if you miss, typically a service credit against the customer's bill. Because money is attached, the SLA is the one that has to be measured with a number you can defend in a dispute, which loops back to the SLI: no credible indicator, no defensible agreement. How those refunds are usually structured is covered in SLA service credits.
A common mistake is to write the SLA first, pulled from a competitor's marketing, then discover you have no way to measure it and no headroom to hold it. Build it the other direction. Decide what you can measure (SLI), set a target you can actually hit (SLO), then promise a level below that target with confidence (SLA). We cover how to choose that promised level in what is a good uptime percentage, and the API-specific version of the same question in what is a good API uptime SLA.
How they work together
Walk one number through all three. Your monitoring reports 99.982% availability this month: that is the SLI. Your internal target is 99.95%, so you are comfortably above your SLO and have error budget to spare. Your customer contract promises 99.9%, the SLA, which you have clearly met, so no service credits are owed. One measured figure, read against two lines, tells you your engineering is healthy and your contracts are safe. That is the whole point of keeping the three straight: measure once, and know both where you stand and what you owe.