8.4 Service level agreements, read critically

Describes cloud observability and reliability practice as of August 2026

What this is and why it exists

A provider's service level agreement is a legal document that most people quote without reading, and reading it changes what you build. It promises less than the number suggests, it pays in a currency that is not money you lost, and it stops being useful the moment you compose several services together. This lesson makes you able to read one and say precisely what it does and does not give you.

The vocabulary

  • Availability percentage — the proportion of a period the service is promised to be usable.
  • Service credit — the remedy an SLA actually provides: a discount on future bills.
  • Exclusion — a circumstance in which the promise does not apply.
  • Maintenance window — planned unavailability that usually does not count against the figure.
  • Unavailable — whatever the agreement defines it to mean, which is rarely what you assume.
  • Composite availability — the availability of a whole made of parts.
  • In series — an arrangement where every component must work for the system to work.

The mental model

Start by converting, always, because a percentage is designed to look reassuring and minutes are not. A thirty-day month holds forty-three thousand two hundred minutes. Ninety-nine point nine percent leaves forty-three minutes; ninety-nine point ninety-five leaves twenty-two; ninety-nine point ninety-nine leaves four point three. Do this every time you see a figure, and the difference between two providers stops being decimal places and becomes "half an hour a month" or "seven hours a month", which is a thing you can hold an opinion about.

Then read what happens when the promise is broken, because this is the part that surprises people. An SLA pays a service credit — a percentage off a future bill, capped, and usually requiring you to apply for it within a deadline. It does not compensate your losses. If an outage costs you a day of sales and your reputation, the agreement returns a fraction of a month's fee for that service, provided you noticed and applied in time. So an SLA is not insurance and should never be used as one. Its real value is as a statement of what the provider is engineering towards, and as a floor under your own planning.

Next, exclusions and definitions, which is where the promise gets its actual shape. Planned maintenance usually does not count. Neither do problems caused by your own configuration, by anything you run on top, by network paths outside the provider, or by force majeure. And the definition of unavailable is frequently much narrower than "not working for me" — it may require total inability to connect, sustained for a minimum period, measured across a region rather than at your machine. A service that is slow but reachable, or failing a fraction of requests, is often not unavailable by the agreement's own definition even though your users are certainly suffering. Read the definition first; it does more work than the number.

Then composition, which is the calculation nobody does. Dependencies in series multiply: if four services each promise 99.9 percent and your request needs all four, the promise for the whole is 0.999 to the fourth, which is about 99.6 percent — around a hundred and seventy minutes a month rather than forty-three. Four nines-of-three components make a system substantially worse than any one of them. Two consequences follow, and both are design decisions: reduce the number of components a request truly depends on, and make some of the remaining dependencies optional, since a dependency you can degrade around drops out of the series calculation entirely. Redundancy works the other way — two independent copies of the same component fail together only when both fail — but only when they really are independent, and two instances in one zone that share the same power are not.

Which brings the lesson to its practical end: write your own objective underneath the composite. You cannot promise more than your dependencies allow, so start from the composed figure, subtract what your own deployments and mistakes will consume, and state something you can meet on a bad month rather than a good one. An internal objective you miss regularly is worse than a modest one you keep, because a target nobody believes stops informing any decision.

What you should now be able to explain or do

Convert any availability percentage into minutes a month in your head. Say what an SLA actually pays and why it is not insurance. Name four common exclusions, and explain why the definition of unavailable matters more than the figure. Compute the composite availability of components in series and say what it does to your promise. Give two ways to improve a composite figure without buying more reliability. Set an internal objective underneath the composite and justify it.

Check yourself

About twenty-two minutes — half of the forty-three that 99.9 allows, out of a thirty-day month's forty-three thousand two hundred.

A service credit — a capped discount on a future bill for that service, usually only if you notice and apply within a deadline. Not your losses. An SLA is a statement of intent, not insurance.

Frequently not. Agreements often define unavailable as a total inability to connect, sustained for a minimum period and measured regionally. Read the definition before the number.

About 99.6 percent — 0.999 multiplied by itself four times — which is roughly a hundred and seventy minutes a month rather than forty-three. In series, availabilities multiply.

Remove dependencies from the critical path so fewer components must work, and make some of them optional so the system degrades instead of failing — an optional dependency leaves the series calculation altogether.

Go deeper

Back to Service level agreements, read critically: work through the checklist