SLAs: The Promise With Money Attached
An SLA is a contract: a reliability promise to a customer with a defined consequence when you break it. It is deliberately looser than your internal SLO, it is written by people who are not on call, and alerting on it means you find out you owe refunds at the same moment as your legal team.
Frame the diagnosis
Performance work starts from a symptom and a signal — never from a resource dashboard.
Three layers, three audiences
The SLI is a measurement, the SLO is an engineering objective, and the SLA is a legal commitment. They are frequently collapsed into one conversation, and the collapse is expensive because each has a different audience, a different consequence and a different appetite for risk. The SLI answers "what happened". The SLO answers "is that acceptable to us". The SLA answers "what do we owe them".
The critical structural property is the gap. The internal SLO sits meaningfully above the SLA, so that violating the objective is an internal signal to slow down and stabilise — a warning, arriving well before any contractual exposure. If SLO and SLA are the same number, that warning space does not exist: the first time the team learns it is in trouble is the moment refunds become payable. A common shape is an SLA at 99.9% with an internal SLO at 99.95%, giving roughly a factor of two in budget between "engineering is worried" and "finance is involved".
SLAs also tend to be measured differently, and usually more favourably to the provider: monthly calendar windows rather than rolling, excluding scheduled maintenance, excluding failures attributed to the customer's own integration, and often measured at a coarse granularity where any successful request in a five-minute bucket makes the bucket count as up. None of that is dishonest — it is how contracts are written to be arbitrable — but it means the SLA number is not comparable to the SLO number even when they look identical.
| SLI | SLO | SLA | |
|---|---|---|---|
| What it is | A measurement | An internal target | A contractual promise |
| Audience | Engineers | Engineering + product | Customers, sales, legal |
| Window | Continuous | Rolling 28d typically | Calendar month typically |
| Consequence of breach | None — it is a number | Freeze risky work, prioritise reliability | Service credits, refunds, exit clauses |
| Who can change it | The owning team | Team with product agreement | Nobody quickly — it is in signed contracts |
| Exclusions | Health checks, client errors | Same as the SLI | Maintenance windows, force majeure, customer-caused |
Never alert on the SLA
Alerting on the SLA is the single most common mistake in this area, and it is worth understanding exactly why it fails rather than just avoiding it. An SLA breach is a business event that has already happened — by the time the contractual threshold is crossed, the outage is over, the customers are affected and the credits are owed. An alert at that moment is a notification, not a call to action. It tells you to write an apology, not to fix a system.
The internal SLO exists to fire *first*, while there is still budget and therefore still time. Because the SLO sits above the SLA, burning through the internal budget is an early warning that contractual exposure is approaching. That is the entire purpose of the gap, and collapsing the two numbers throws it away.
There is a second-order failure too: SLA measurement is usually coarse and lagging by design — monthly buckets, generous exclusions, aggregation rules negotiated for arbitration rather than for detection. It is genuinely bad telemetry for operational purposes. Alerting on it produces pages that arrive late, based on a number computed differently from everything else the team looks at, which nobody can reconcile against the dashboards during an incident.
1ALERT: SlaBreach2 expr: monthly_availability < 0.9993 for: 1h4 page: on-call5 6# fires: 2026-03-31 23:40, after a month of accumulation7# the outage that caused it was on 2026-03-148# the on-call engineer can do exactly nothing about it9# and the number does not match any operational dashboard1ALERT: CheckoutBudgetFastBurn # pages2 expr: burn_rate_1h > 14.4 AND burn_rate_5m > 14.43 slo: 99.95% internal, 28d rolling4 note: at this rate ~2.1% of the 28d budget is gone in 1 hour5 6REPORT: sla_compliance_monthly # dashboard + monthly review7 expr: monthly_availability_contractual8 note: computed per contract terms; reviewed with finance,9 never paged on — by the time it moves it is historyThe left-hand alert reports a financial fact after the fact. The right-hand alert fires while budget remains, on the same telemetry the team debugs with, and leaves the contractual number where it belongs — in a monthly report read by the people who can act on it commercially.
What the contract actually says matters operationally
Engineers routinely design against an SLA they have never read, and the details change what "compliant" means. Three clauses matter most. First, the measurement definition: many SLAs define downtime in coarse buckets — a five-minute interval counts as down only if *all* requests in it failed — which means a service losing 30% of requests continuously for a week may be contractually at 100% availability while being obviously broken. Second, the exclusions: scheduled maintenance announced in advance usually does not count, which is why maintenance windows exist as a contractual instrument and not just an operational one. Third, the remedy: service credits are typically capped at a fraction of the monthly fee and usually must be claimed by the customer within a window, so the real financial exposure is often far smaller than the headline suggests — and the reputational exposure far larger.
The asymmetry between financial and reputational cost is worth stating plainly, because it changes prioritisation. A breach might cost 10% of one customer's monthly fee and cost you the renewal. Teams that argue about reliability investment purely in credit-liability terms consistently under-invest, because they are pricing the smaller of the two costs.
Finally: a customer-facing status page is not an SLA, and treating it as one causes its own pathology. Status pages are communication tools with their own incentives — the temptation to report "degraded" instead of "down" is real and well documented across the industry. Keep the status page honest by driving it from the same SLI the team debugs with, rather than from a separate judgement call made under pressure.
| Signal | Value | What it tells you | Verdict |
|---|---|---|---|
| Contractual availability (5-min all-fail buckets) | 100% | No bucket had 100% failures — contractually a perfect week | normal |
| Request success rate | 71% | Nearly a third of all requests failed, continuously | smoking gun |
| Internal SLO budget remaining | -340% | The internal objective caught it immediately; the contract did not | smoking gun |
| Support tickets | +780% week over week | Users experienced the outage the contract says did not occur | smoking gun |
| Service credits owed | $0 | Correct per the contract, and irrelevant to whether customers renew | suspect |
Key points
- SLI is a measurement, SLO is an engineering objective, SLA is a legal commitment — different audiences, different consequences, different windows.
- The internal SLO must sit meaningfully above the SLA; that gap is the warning space between "engineering is worried" and "finance is involved".
- Never page on the SLA: it is coarse, lagging and reports a business fact that has already happened.
- SLA measurement rules (all-fail buckets, exclusions, monthly calendar windows) can report 100% during a week users experienced as broken.
- Credit liability is usually the smaller cost; pricing reliability purely by contractual exposure systematically under-invests.
Follow the diagnosis
The causal chain, hop by hop — and the readings that invite the wrong conclusion.
- 1Sales → contract: promises 99.9% monthly availability with standard exclusions.
- 2Team → objective: adopts 99.9% as the internal SLO too, leaving zero gap.
- 3Incident → budget: a four-hour degradation consumes the entire month's budget in one afternoon.
- 4Alert → on-call: fires only once the contractual threshold is crossed, hours after the outage ended.
- 5Finance → team: learns about the breach from the same alert, at the same moment, with no advance warning to manage the customer relationship.
- • Reading contractual compliance as evidence that users were fine — the measurement rules may be structurally unable to see partial failure.
- • Assuming the SLA and SLO measure the same thing because they carry the same percentage.
- • Treating service-credit exposure as the total cost of a breach, ignoring renewals and reputation.
- • Believing a maintenance-window exclusion makes the downtime invisible to users — it makes it invisible to the *contract*.
- • Using the status page as the source of truth for whether an incident occurred.
Measure, fix, validate
An optimization is not finished until the metric that motivated it has moved.
- • Track internal SLO budget and contractual SLA compliance as two separate series, computed by their own rules, displayed side by side.
- • Compute the SLA number exactly as the contract defines it — including bucket granularity and exclusions — rather than approximating it from the SLI.
- • Monitor the gap between the two: if contractual compliance is high while the SLO is burning, the contract's measurement rules are hiding real user pain.
- • Report SLA compliance monthly to the people with commercial authority; keep it off the on-call dashboard.
- • Set the internal SLO at least one meaningful step above the SLA — roughly a factor of two in budget is a workable default.
- • Move all paging to internal budget burn; report SLA compliance monthly and never page on it ([[burn-rate-alerts]]).
- • Read the actual contract and encode its measurement rules faithfully, including bucket granularity and exclusions.
- • Drive the public status page from the same SLI the team debugs with, so degradation cannot be quietly reclassified under pressure.
- • Bring engineering into SLA negotiation before signature — a number nobody checked against current behavior becomes an engineering constraint permanently.
- • Back-test the last two quarters: confirm the internal SLO would have fired before every contractual breach, with usable lead time.
- • Replay a known partial-failure incident through the contractual measurement rules and check whether it registers at all.
- • Confirm the on-call alert set contains no rule whose expression references the contractual metric.
- • A higher internal SLO than the SLA costs real engineering effort to defend a target no customer contractually requires.
- • Encoding contractual measurement rules faithfully means maintaining a second, deliberately less useful metric pipeline.
- • An honest status page driven by the SLI will show degradation that a judgement call might have downplayed — better for trust, occasionally worse for a quarter.
- • Re-check the SLO-to-SLA gap whenever either number changes; a renegotiated SLA can silently close it.
- • Review the contractual measurement definition annually against how the service actually fails — bucket rules that made sense for a monolith often do not for partial degradation.
- • Add SLA terms to the engineering review checklist for new enterprise contracts.
Accuracy
Performance numbers are conditional. These are the conditions.
- ILLUSTRATIVEThe 99.9% SLA / 99.95% SLO pairing and the all-fail bucket example are common industry shapes used to teach the structure; actual contract terms vary enormously and only your contract governs.
- ENVIRONMENT-SPECIFICWhether coarse-bucket measurement is even feasible depends on what your provider or load balancer exposes; some stacks cannot reproduce contractual definitions without a separate pipeline.