SLA vs SLO vs SLI: What Each One Means and Why the Difference Matters

SLA, SLO, and SLI get used as if they were three spellings of the same idea. They are not. One is a measurement. One is an engineering target. One is a contractual promise with money attached. When a sales call, a board update, and an on-call rotation all mean different things by "99.9%," you do not have a reliability program. You have a vocabulary collision waiting to become a credit memo.

This post defines the three terms the way engineering and customer contracts actually use them. If you already live in error budgets and want help choosing targets, read pick the right SLO before you worry about the error budget next. Start here if the letters still blur together.

SLI. What you measure

A Service Level Indicator is a raw measurement of a system behavior. It is a fact about what the system did, not a promise about what it should do.

Common SLIs

• Availability. Successful requests divided by total valid requests.
• Latency. p95 or p99 response time for a critical endpoint.
• Error rate. Failed requests divided by total requests.
• Freshness or correctness, for pipelines and data products.

If you cannot graph it from real traffic or synthetic checks, it is not an SLI yet. "The API feels fine" is not an indicator. "99.92% of checkout POST requests returned non-5xx in the last 30 days" is.

SLO. What you target internally

A Service Level Objective is the internal target for an SLI. Your team commits to itself, and that commitment drives engineering tradeoffs.

Example. "We will maintain 99.9% availability for the payment API over a rolling 30-day window."

SLOs decide when you slow feature work to stabilize, when a page is justified, and when a postmortem is mandatory. Missing an SLO is an engineering signal. It should hurt in planning, not in a courtroom.

SLA. What you commit to contractually

A Service Level Agreement is the contractual commitment to an external party, usually a customer. It includes the metric, the measurement window, exclusions, and what happens when you miss.

Example. "If availability falls below 99.5% in a calendar month, we will issue a 10% service credit."

Violating an SLA is a legal and financial event. Support and sales will care. Finance will care. Engineering should care earlier, which is why the SLO exists as a stricter tripwire.

Why the distinction matters

| Concept | Audience | Miss means | | --- | --- | --- | | SLI | Engineering instrumentation | You are blind or you are informed | | SLO | Internal engineering and product | You are burning reliability faster than planned | | SLA | Customer contract | Credits, escalations, renewal risk |

If leadership quotes the SLA number as the engineering target, the team will only react when money is already in play. If sales quotes the SLO number in contracts, you have given away your buffer. Keep the layers separate on purpose.

The SLO should be stricter than the SLA. Engineering catches the problem while there is still room before the contractual floor.

The error budget

The error budget is the space between perfect operation and the SLO. For a 99.9% availability SLO, you have about 43.8 minutes of allowable downtime per month. That budget is what you spend on deploys, incidents, and experiments.

When the budget is healthy, you can ship. When it is nearly gone, you stabilize. Teams that never compute the budget treat every outage as a surprise and every launch as unrelated. The math connects them.

For a sharper take on how expensive extra nines become, see the real cost of five nines.

How to set realistic SLOs

Start from historical data, not aspirational branding.

If the payment API has run at 99.7% for the last two quarters, writing a 99.99% SLO without changing architecture, staffing, or testing is a plan to fail every month. Either invest until the indicator can support the target, or set a target the system can hold while you improve.

Good SLO habits

• Pick SLIs users feel, not vanity internals.
• Use a clear window, rolling 30 days or calendar month, and stick to it.
• Review the target when the architecture changes, not only when someone wants a rounder number.
• Resist copying Google's public numbers for a six-person team.

What enterprise SLAs usually include

When you negotiate an enterprise SLA, expect more than a percentage.

• Availability definition. Which endpoints count, and what counts as success.
• Measurement window. Calendar month is common. Rolling windows appear too.
• Exclusions. Scheduled maintenance, customer-side errors, third-party failures outside your control. The exact wording matters.
• Credit structure. Tiered credits are common. 10% for a miss, more for a deeper miss.
• Calculation method. Successful requests over valid requests is cleaner than "the status page was green."
• Reporting. How the customer can verify the number.

Do not let sales invent the measurement method in a slide. Engineering has to be able to produce the same number the contract implies.

Worked example. SaaS payment API

SLI. Availability measured as successful transaction responses over total valid transaction requests in a rolling 30-day window. A successful response is HTTP 2xx or an expected business 4xx such as a declined card. 5xx and timeouts count as failures.

Internal SLO. 99.7% availability on that SLI. Error budget is about 0.3% of requests, which the team reviews weekly.

Customer SLA. 99.5% availability for enterprise customers on the same style of calculation, calendar month, with stated exclusions for scheduled maintenance announced 48 hours ahead. Miss triggers a 10% monthly fee credit.

Why this shape works

• Engineering feels pain at 99.7%, before the contract floor at 99.5%.
• The SLI matches user-visible checkout failures, not CPU graphs.
• Sales can sell 99.5% without promising the internal stretch target.

If a bad week burns the SLO budget, feature freezes and reliability work take priority. If the month still clears 99.5%, customers may never see an SLA credit, which is the point of the buffer.

Reporting without three different truths

Pick one calculation path and reuse it in engineering reviews, customer reports, and sales collateral. If engineering measures rolling 30-day request success and the MSA implies calendar-month component uptime on a status page, you will eventually publish two numbers that disagree. That disagreement becomes a support incident of its own.

Publish the method next to the number. Window, success definition, and exclusions. Stakeholders argue less when the arithmetic is visible.

Use the words on purpose

Say SLI when you mean the measurement. Say SLO when you mean the engineering target. Say SLA when money and contracts are in play. The discipline feels pedantic until the first time someone commits your stretch goal in a customer MSA.

Vigiles tracks uptime against the targets you set so the indicator and the objective stay visible beside the incidents that burn the budget. The contract language still belongs to you and your counsel. The numbers should not be a surprise when finance asks for them.