SLI, SLO and SLA Explained, in depth: from a measured indicator to a contract you can afford

Three layers, three audiences

An SLI is a ratio of good events to valid events, for example the share of HTTP requests that returned a non-5xx response in under 300 ms. It has no target; it is just a number over a window. An SLO adds a target and a window: 99.9 percent of requests good over a rolling 30 days. The shortfall the SLO allows, 0.1 percent of requests, is the error budget, which the team spends on releases, experiments and incidents. An SLA is an external promise with consequences, usually service credits, sometimes the right to terminate.

Downtime arithmetic

Percentages hide how small the numbers are. A 30-day month has 43,200 minutes and a 365-day year has 525,600, so each target converts directly into allowed bad time. These are worth memorising, because they make an unrealistic proposal obvious in a meeting.

At 99.99 percent a single slow rollback or a ten-minute DNS mistake uses two months of budget. If your deploy, detection and rollback take longer than four minutes end to end, a four-nines promise is a promise to pay credits.

Anatomy of an SLA

An SLA is a legal document, but each clause has an engineering meaning. If engineering does not review these clauses, the contract will define availability in a way your SLI cannot measure.

The definition of unavailable is the most important clause. "Bad minutes" (a minute counts as down if more than, say, 5 percent of requests fail) and "bad requests" (each failed request counts) give very different numbers for a partial outage. Pick the one your SLI already measures, and write the threshold into the contract.

Composite availability: what your dependencies allow

Your service cannot be more available than the chain it depends on. If a request must pass through components in series, and failures are independent, availability multiplies. If redundant copies run in parallel and any one is enough, unavailability multiplies instead.

from math import prod

def series(*avail):            # every component must work
    return prod(avail)

def parallel(*avail):          # any one replica is enough
    return 1 - prod(1 - a for a in avail)

lb, app, db = 0.9999, 0.9995, 0.9995
one_region = series(lb, app, db)                 # 0.99890 -> about 47 min/month down
two_regions = parallel(one_region, one_region)   # 0.9999988 if failures were independent
print(f"{one_region:.5f}  {two_regions:.7f}")

One region of load balancer, application and database gives about 99.89 percent, which is already below a 99.9 percent SLO before you count your own bugs. Two regions look like nearly six nines on paper. They are not, because the independence assumption is false: both regions share your deployment pipeline, configuration, DNS provider, identity service and your own code. A bad config pushed everywhere takes both down at once. In practice, correlated failures set the ceiling, so budget for them directly. One simple model is to multiply the parallel result by the availability of the shared components.

Do this calculation before signing. If a dependency's own SLA is 99.9 percent, you cannot promise 99.95 percent on top of it without redundancy that removes the dependency from the critical path, and its credits will not cover yours.

Worked example: setting an SLA from SLO history

A team runs an API with a 99.9 percent SLO measured as request success. Sales wants to offer an SLA. The team exports twelve months of calendar-month availability from the same SLI: most months are between 99.93 and 99.99 percent, one month had a 70-minute incident at 99.84 percent, and one was 99.6 percent after a database failover went wrong. They evaluate three candidate SLAs with an illustrative credit schedule of the common shape: 10 percent of the monthly fee below the promise, 25 percent below a lower tier, and 50 percent below a third tier.

HISTORY = [99.97, 99.95, 99.99, 99.84, 99.96, 99.93,
           99.98, 99.60, 99.95, 99.97, 99.99, 99.94]   # calendar months, percent

def credit_rate(avail, promise):
    tiers = [(promise, 0.10), (promise - 0.5, 0.25), (promise - 4.0, 0.50)]   # illustrative
    rate = 0.0
    for threshold, pct in tiers:
        if avail < threshold:
            rate = pct
    return rate

def exposure(promise, monthly_fees_total):
    months = [credit_rate(a, promise) for a in HISTORY]
    breaches = sum(1 for r in months if r > 0)
    cost = sum(r * monthly_fees_total for r in months)
    return breaches, cost

for promise in (99.95, 99.9, 99.5):
    b, cost = exposure(promise, monthly_fees_total=200_000)
    print(f"SLA {promise}%: {b} breached months, credits {cost:,.0f} per year")

With these inputs, a 99.95 percent SLA would have been breached in four months (99.84, 99.93, 99.60 and 99.94), all at the 10 percent tier because even 99.60 stays above the second tier at 99.45. With fees of 200,000 a month across SLA customers, that is 80,000 a year in credits, and four disappointed customers. A 99.9 percent SLA would have been breached twice, in the 99.84 and 99.60 months, for 20,000 each, 40,000 in total. A 99.5 percent SLA would not have been breached at all. The team offers 99.5 percent, keeps the internal SLO at 99.9 percent, and so has a margin of 0.4 percentage points, about 173 minutes a month, between the point where engineering reacts and the point where credits are owed.

Real customers do not all claim, and fees vary by customer, so refine the model with your claim rate and revenue split. The method matters more than the numbers: never sign an SLA you have not replayed against your own history.

What belongs in the contract and what stays internal

A service usually has several SLOs but sells far fewer SLA terms. Availability is the common contractual promise because both sides can agree how to measure it. Latency is harder: a percentile depends on payload size, client location and the customer's own network, so a latency SLO normally stays internal, or appears in the contract only as a narrowly defined server-side measure on named operations. Data durability, support response times and recovery objectives for disaster events are often promised separately, each with its own definition and remedy.

Every SLA term needs an internal SLO behind it, set tighter, measured with the same definition and alerting early. The reverse is not true: most SLOs never become contract terms. Keep internal objectives for things customers feel but cannot easily measure, such as freshness of search results, queue delay for background jobs, or the quality of model outputs, tracked as judged samples (see SLOs for AI applications). Those objectives guide engineering decisions without creating financial liability.

Measuring what the contract measures

Customers measure from outside, and you measure from inside. A load balancer can report success while customers fail at DNS or TLS, which your server logs never see. Run synthetic probes from several networks against the exact covered endpoints, and keep their results as evidence for disputes. Use server-side request data for the SLI and probes as a cross-check; when they disagree, investigate before the customer's claim arrives.

Alert on the SLO, not the SLA. By the time an SLA threshold is crossed, the money is already owed. Burn-rate alerts against the SLO give hours or days of warning, which is the whole point of keeping the SLO tighter.

Failure modes

The SLO playbook covers the budget policy that gives the internal layer teeth.

What to do next

1. Write down, for one service, its SLI definition, its SLO, and any SLA it is sold under, side by side.
2. Check that the SLA's definition of unavailable can be computed from your SLI data; if not, change one of them.
3. Compute series availability for your critical path and compare it with your SLO.
4. Export twelve months of calendar-month availability and replay every proposed SLA through a credit calculator.
5. Keep a margin of at least several times your typical monthly burn between SLO and SLA.
6. Set alerts on SLO burn rate, and add external probes for every endpoint an SLA covers.