SLA vs SLO vs SLI: What Each One Means and Who Owns It

An SLI is the measurement, an SLO is the target you set for that measurement, and an SLA is the contract that attaches a financial consequence to missing it. They stack in that order: you cannot have a meaningful SLO without an SLI to measure it, and you should not sign an SLA without an SLO that sits comfortably inside it. Google defines an SLI as a carefully defined quantitative measure of some aspect of the level of service provided, an SLO as a target value or range for that measure, and an SLA as an explicit or implicit contract that includes consequences for missing the objectives it contains.

The three get used interchangeably in meetings, which is how teams end up promising customers a number that engineering has never measured. Keeping them apart is not pedantry. Each one has a different owner, a different audience, and a different thing that happens when it is missed.

SLA vs SLO vs SLI: the difference in one table

Microsoft draws the same line in its Well-Architected Framework and adds the part people most often miss: an SLA is a formal contract with direct financial and legal implications, while organizations use SLOs to evaluate whether potential downtime is still within tolerable limits. The two are related but should be controlled independently.

One metric, run through all three

Take a checkout API. The three layers look like this.

The SLI is the proportion of requests to POST /checkout that return a 2xx status within 500 milliseconds, measured over a rolling 30 day window from outside your network. Note how specific that has to be. Which endpoint, which statuses count as success, what latency ceiling, measured over what window, from where. A vague SLI produces an SLO nobody can adjudicate.

The SLO is that this figure stays at or above 99.9%. On a 30 day month that permits 43 minutes 12 seconds of failure, which is your error budget for the month. Spend it slowly and you ship features. Spend it in one afternoon and the next two weeks belong to reliability work.

The SLA is the clause in your customer contract that says if monthly availability falls below 99.5%, the customer receives a 10% service credit. Notice the gap: the internal target is 99.9% and the contractual floor is 99.5%. That gap is deliberate, and it is the single most important design decision of the three.

Why the SLO should be stricter than the SLA

The SLO is the alarm and the SLA is the wall. You want the alarm to go off with room left to react. If your internal objective and your contractual commitment are the same number, then the first time you notice you are in trouble is the moment you already owe money.

Setting the SLO tighter buys you a buffer measured in real minutes. In the checkout example above, the 0.4 percentage point gap between 99.9% and 99.5% is roughly two and a half hours a month of degradation that costs you internally, in slowed releases and reprioritized work, before it costs you contractually. That is the window in which you fix things.

It is worth knowing that this rule gets broken deliberately. Microsoft's own reference example works out a composite objective of 99.45% a month for a workload, roughly four hours, and then has the legal and finance departments set the customer facing SLA at 99.90%, a stricter promise than engineering predicts it can hold. Microsoft describes this plainly as a calculated risk taken to benefit the business, with the engineering team aware of the commitment. If you are going to invert the rule, invert it on purpose and with everyone informed, not by accident because nobody checked what the number added up to.

Where KPIs fit

A KPI is a business measure of whether something is working commercially: signups, retention, revenue per account. An SLI is a technical measure of whether the service is behaving. They overlap when reliability is the thing driving the business number, and confusing them is how a reliability review turns into a growth meeting.

The clean split: an SLI has a threshold you can breach at 3am and page someone about. A KPI has a trend you review monthly. If someone proposes an SLO on a number nobody could act on inside an hour, it is probably a KPI wearing the wrong hat.

How many SLOs should you have?

Fewer than you want. Google's guidance is to choose just enough SLOs to provide good coverage of the system's attributes, and it warns specifically against two failure modes at the ends of the range. Targets so aggressive that they demand heroic effort to sustain will burn the team out, and targets so lax that nobody notices a breach will let product quality slide. Both waste the work of having SLOs at all.

Google also advises against picking a target simply because it matches current performance. Today's numbers may be the product of luck, low traffic, or an unsustainable amount of manual intervention, and enshrining them as an objective locks you into supporting them forever.

In practice, one availability SLO and one latency SLO per user facing service covers most of the value. Add a correctness or freshness objective only where getting it wrong is genuinely worse than being down.

The mistakes that show up most often

Measuring the SLI from inside your own network. A check that runs on the same host as the application will report the application healthy during a DNS failure, a certificate expiry or a load balancer misconfiguration, all of which are total outages for your customers. If the SLI is meant to describe customer experience, it has to be measured from where the customer is.

Averaging away the incident. A 30 day average hides a four hour outage inside an otherwise perfect month. This is what error budgets are for: they express the same figure as a quantity you spend rather than a percentage you report, which makes a single bad afternoon visible. Our guide to error budgets covers the burn rate thresholds that turn that into alerting.

Forgetting the dependencies. If your service calls three others that each promise 99.99%, your ceiling is already 99.96% before you write a line of code, because availability multiplies down a dependency chain. Work the number out before you commit to it. The SLA calculator does the composite arithmetic across a chain and shows what the total allows in minutes.

Nobody owns the breach. An SLO that is missed and merely discussed is decoration. The breach should create a specific piece of work that lands on a named owner rather than in a channel where everyone assumes someone else picked it up.

Measuring the SLI so the number is defensible

Whichever objective you set, the measurement has to survive scrutiny from someone who would prefer it said something else. That means checks from outside your infrastructure, from more than one location, with timestamps you did not write by hand after the fact.

Multiple regions matter more than most teams expect. A single probe cannot distinguish between your service being down and the path between that one probe and your service being down. Checking from several places and requiring agreement before recording an outage keeps routing blips out of the number, which matters because those blips are what make an availability figure arguable.

Uptimehub runs HTTP, API, SSL, DNS, TCP port and cron heartbeat checks from six regions with auto retry from a second region before anything is recorded or alerted. SLA monitoring tracks measured availability against the target you set, so the SLI behind your SLO is a continuous record rather than a reconstruction. If you need to know how much downtime a given percentage actually permits, the uptime calculator converts between the two in both directions.

Common questions

Is an SLO legally binding? No. An SLO is an internal target with no contractual force. The SLA is the binding document. This is exactly why the two should be different numbers: the SLO can be moved as you learn more about the system, while changing an SLA means renegotiating with customers.

Can you have an SLA without an SLO? Technically yes, and it is a bad idea. You would be promising customers a number you have no internal target for and no early warning against. Google's definition builds the dependency in: an SLA is a contract that includes the consequences of meeting or missing the SLOs it contains.

What is a good SLO to start with? One availability objective on your most important user flow, measured externally, set at a level you have actually sustained for a quarter without heroics. Tighten it later. Starting loose and tightening is far easier than announcing a target you then have to walk back.

Do SLAs apply to free tiers? Usually not. Most providers exclude free, trial and preview services from any financially backed commitment. If you are building on a free tier, you have no contractual recourse, which makes your own measurement the only evidence you will ever have.

Where to start

Pick one user flow that matters commercially. Define the SLI precisely enough that two people would compute the same number from the same data. Set the SLO at a level you have already sustained. Then work out what your dependencies allow before you let anything reach a customer contract, because that arithmetic is what decides whether the promise was ever keepable.