SLA vs SLO vs SLI: Which One You Have to Build

SLA vs SLO is a question about who you are promising, and to whom. An agreement is a contract with a customer that carries money attached. An objective is an internal target your team owns. Underneath both sits an indicator, the actual measurement, which is the only one of the three that anybody has to build.

SLA vs SLO vs SLI in one table

The three layers stack. The indicator measures reality, the objective sets the target, and the agreement turns that target into a commercial promise with consequences.

	SLI	SLO	SLA
What it is	A measured number	An internal target	An external contract
Audience	Engineers	Engineers and product	Customers and legal
Example	99.93% of checks succeeded	99.95% over 30 days	99.9% monthly or a 10% credit
Consequence of a miss	None, it is a fact	Freeze releases, spend the budget	Service credits, a breach
Who owns it	The team that measures	The service owner	The commercial side

Google Cloud's SRE fundamentals post is the original short version of this, and Atlassian's explainer is the one most teams have read. Both stop at the definitions, which is where the interesting part starts.

Which one should be stricter?

The objective, always, and by a visible margin. If you promise a customer 99.9% and your team aims at 99.9%, then the first bad month is a contract breach rather than a warning. Aim internally at 99.95% and the gap between the two becomes your reaction time.

Alex Ewerlof makes this point well: the objective quoted inside an agreement deliberately promises less reliability than the one the team works to. People search this comparison both ways, and the SLO vs SLA ordering usually signals an engineer rather than a buyer, but the answer is the same either way.

A practical margin is one step on the nines ladder. Promise three nines externally, run four nines internally, and you have about 40 minutes of monthly slack between the alarm and the invoice. The five nines math explains why the top of that ladder stops being measurable.

Where does the SLI number actually come from?

This is the question the definitional articles skip. An indicator is not a given quantity. It is a choice about what you count, and three decisions inside it change the answer by a wide margin.

What counts as a failure. A 200 response carrying an error page is a success by status code and a failure to the user. An indicator built only on status codes flatters you. Add a body assertion so the check reads what came back.

How often you sample. A one-minute check produces 43,200 samples a month. Each failed sample costs roughly 0.0023 percentage points, so a single bad check moves a 99.95% indicator to 99.9477%. Three consecutive failures cost you 0.007 points. Know the size of one sample before you argue about a target.

Where you measure from. Availability measured from one region is availability for that region. We prefer running the indicator from three regions and taking the worst, not the average, because the average lets a healthy region paper over a broken one.

There is also a category difference worth being honest about. A check schedule produces a time-sampled indicator, not a request-weighted one. If 90% of your traffic arrives in a two-hour window, an evenly sampled indicator underweights exactly the hours that matter. Request-weighted numbers need instrumentation inside the application, so an outside-in indicator is an approximation, a good one, but an approximation.

Error budgets turn the objective into a decision

An error budget is the inverse of the objective. A 99.9% target over 30 days permits 43 minutes and 28 seconds of failure, and that allowance is a resource you get to spend. Ship a risky migration on a Tuesday and it costs budget rather than goodwill.

Objective	Monthly budget	What that buys
99.0%	7h 18m	Weekly maintenance windows
99.9%	43m 28s	One bad deploy and a rollback
99.95%	21m 44s	A fast rollback, nothing more
99.99%	4m 21s	Automated failover only

The rule that makes this work is boring and unpopular: when the budget is gone, feature work stops until reliability work refills it. Google's SRE book describes the policy in full. Without that consequence an objective is just a number on a dashboard.

Building an indicator you can defend

Define the check so that the number it produces matches the sentence in your agreement. Assert on status, on latency and on content, then run it from several regions.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "orders api slo",
    "type": "keyword",
    "target": "https://example.com/api/orders/health",
    "intervalSec": 60,
    "regions": ["london", "los-angeles", "singapore"],
    "keyword": "\"db\":\"ok\"",
    "keywordMatch": "contains",
    "expectedStatus": [200],
    "responseTimeThresholdMs": 800
  }'

Two defaults matter here. A probe error never counts as a down vote, so a failure in the monitoring path does not quietly spend your budget. And a failing check moves through SUSPECT before DOWN, confirmed from a second region, which is the mechanism described in cross-region quorum confirmation.

Match your reporting period to your retention. A quarterly objective needs at least a quarter of stored history. Retention runs one month on the free tier, a year on Individual and two years on Enterprise as of September 2026. The pricing page lists the current limits, and raw check data comes out of the REST API if you calculate the number yourself.

SLA vs SLO in a worked example

Take a payments API with a 99.9% contractual promise and a 99.95% internal target, both measured over a rolling 30 days. The contract allows 43 minutes 28 seconds of failure. The internal target allows 21 minutes 44 seconds. That 21-minute gap is the whole safety margin, and it is what you are managing week to week.

A 60-second check gives 43,200 samples in the window. Missing the internal target takes 22 failed samples. Breaching the contract takes 44. Those are small numbers, which is the point: a single 15-minute incident spends two thirds of the internal budget in one afternoon.

So the alerting policy writes itself. Page someone at 50% budget burn, because 11 minutes of failure means the month is now fragile. Freeze non-essential deploys at 75%. At 100% you are still inside the contract with 21 minutes to spare, which is exactly the cushion the two-tier design bought you.

Write the same arithmetic down for every service before anyone signs anything. It converts an argument about percentages into an argument about minutes, and minutes are something a team can reason about honestly.

Common mistakes

Copying a cloud provider's agreement. Their number describes their infrastructure, not your application. Your availability is the product of every dependency you call, so it is always lower than the weakest link you rent.

Writing an agreement before you have an indicator. In our testing the number a team assumes and the number a probe reports differ by more than anyone expects. The cause is usually a TLS renegotiation or a cold start that nobody had measured. Measure for a month, then promise.

Treating latency as pass or fail. Slow is a separate indicator from down, and it deserves its own target on a percentile. That distinction is the subject of response time monitoring, and the four golden signals keep the two apart for the same reason.

Setting one objective for the whole product. Checkout and the marketing site do not deserve the same target or the same pager policy.

Read SLA vs SLO as a sequence rather than a comparison. Pick an indicator you can measure honestly, set an objective a step stricter than anything you sign, and let the error budget decide when to slow down. The measurement is the part you have to build, and you can have the first one running against a real endpoint in a few minutes on the free plan.