Your SLOs before your SLAs

The SLA always arrives from the wrong end. A partner contract is being negotiated, the someone on the sales side asks "can we put 99.9%?", someone answers "the platform is solid", and the figure goes into the contract. Nobody looked at a single measurement before signing.

Six months later, an incident reveals that the API in question goes through a backend that restarts every night. The promised 99.9% was mathematically impossible to hold from the day it was signed.

The three letters in order

The vocabulary is well known but the order is almost always reversed.

SLI first: the indicator. What do we measure, where, and how? "Availability" means nothing until you have answered: measured from where (the gateway, the client, an external probe), on what (the 5xx error rate, the share of responses under a latency threshold), over which window.

SLO next: the internal objective. The level the team sets itself, measured by the SLI, with an explicit margin for error. It is a steering tool, not a contract: you are allowed to miss it, and missing it triggers a conversation, not a penalty.

SLA last: the contract. An external commitment, with penalties, set below the demonstrated SLO. Below it, not level with it: if you hold a demonstrated 99.95% over twelve months, you can sign 99.9%. If you measure nothing, you can sign nothing, you can only bet.

What an API can promise

An API cannot be more available than the chain it runs through. Gateway, network, identity provider, backend, backend dependencies: compounded availability degrades at every link.

This is the calculation that cools enthusiasm: a gateway at 99.95% in front of a backend at 99.5% gives a chain at 99.45% in the best case. Promising 99.9% on that chain is promising the weather.

Hence a practical consequence: an API's SLA is built backend by backend, not at platform level. The platform can publish a global commitment on what it controls. Every API inherits the floor set by its dependencies.

The minimum tooling

Holding an SLO takes three things, all supplied by a properly observed platform:

1. the SLI computed continuously from the gateway logs, per API and per consumer, not a global figure that drowns the problems.
2. an error budget: the amount of downtime the objective allows over the window, and its consumption in real time. It is the figure that turns debates of opinion into decisions: budget spent, releases are frozen.
3. the measurement of exclusions: scheduled maintenance, external dependency outages, the contract's force majeure cases. If they are not measured separately, the first partner dispute will sink into manual reconstruction.

The hidden benefit

The SLO exercise has a valuable side effect: it forces an inventory of every API's real dependencies. To set an objective, you have to know what the call goes through, and that work systematically turns up surprises: the critical backend hosted on a machine with no redundancy, the synchronous call to a SaaS nobody had noted, the certificate shared across eight APIs.

In other words, you start the exercise to prepare a contract and come out with a map of the weak points. It is often the first useful deliverable, before even the first published objective.