SLA Measurement Point

Two parties can agree on 99.99% and 200 ms and still be in dispute a quarter later, because they never agreed where those numbers are observed. At the provider's load balancer, at the provider's application, at the consumer's client, or in a synthetic probe from a third location are four different numbers, and the gaps between them are large enough to swallow the commitment entirely.

The measurement point also decides who owns which failures. Measured at the edge, the internet between the two parties is the consumer's problem; measured at the client, it is the provider's. Neither is wrong. Only one is written down, and usually neither is.

Why it matters

Negotiations focus on the percentage because it is the number executives understand. The percentage is the least disputed part of an SLA in practice. What produces the argument is whether a period counts as downtime at all: a partial failure affecting one endpoint, a degradation that returns errors to 3% of requests, a maintenance window nobody recorded, a client-side retry storm that the provider's rate limiter correctly rejected.

Quantitatively, the definitions matter more than the number. 99.99% is about 4.3 minutes a month and 99.9% is about 43 minutes, and a single disputed 20-minute incident moves you between them.

Implementation patterns

• Name the observation point explicitly and, where possible, the specific metric and system that produces it. "Provider-side p99 of successful responses at the API gateway, excluding 4xx" is a definition; "99.99% availability" is an aspiration.
• Define what counts as an error. 5xx only, or also timeouts, also 429s, also 200s with an error body. The last one is what catches partial degradation and is usually omitted.
• Define the measurement window and the aggregation: a month of minute-buckets marked good or bad is a different commitment from an aggregate over all requests, and a low-traffic hour can swing the second dramatically.
• Agree exclusions in advance: announced maintenance, consumer-side rate limit breaches, force majeure, failures of a dependency the consumer specified.
• Publish the numbers continuously rather than at dispute time. A shared dashboard removes most arguments, because both sides watch the same series.
• Scope the commitment to the endpoints that matter, which is usually two or three, rather than accepting a blanket number over an entire API.

Industry example

Public cloud SLAs, published and revised continuously since the first compute SLAs appeared around 2008, are the reference implementations, and they are worth reading as negotiation artefacts rather than as marketing: they define error rate per five-minute or one-minute interval, enumerate exclusions at length, scope commitments per service and per region, and cap remedies at service credits rather than damages. The asymmetry is instructive — the provider's SLA defines everything the provider needs defined, which is exactly what a consumer's counter-draft should do in the other direction.

Failure scenarios

• The unmeasurable commitment, where neither party instruments the agreed point and the dispute is settled by whoever has better logs.
• Averaged-away degradation: a failure affecting 5% of users for a day passes a request-weighted availability target comfortably.
• The client-side tail, where the provider meets 200 ms at the edge and the consumer's users see 900 ms because of connection setup, geography and their own retries.
• Penalty theatre, where the remedy is a credit worth less than the cost of measuring the breach, so the SLA changes nobody's behaviour.

Trade-offs

Precise definitions cost negotiation time and produce a longer contract, and they remove the comfortable ambiguity that lets both sides sign. What they buy is that the commitment is enforceable and, more usefully, that it is engineerable: a team can only build to a target they can measure. Leaving it vague keeps the deal moving and transfers the cost to whichever party has less evidence during the first dispute.

When not to use it

For an internal consumer, most of this is overhead. Between two teams in one company the useful artefact is a published SLO with a shared dashboard and an agreed conversation when the error budget is spent, not a contractual definition with exclusions. Formal measurement points earn their cost where money, penalties or a regulator are attached. The one part worth keeping internally is the measurement point itself, because teams that disagree about where a number is taken will disagree about whether the number was met.

Interview question

Q: A partner reports that you breached your 99.95% availability commitment last month. Your dashboards show 99.98%. Before anyone escalates, what do you check?

What a strong answer covers: where each side measures, and whether the difference is client-side network, DNS or their own retries · what each side counts as an error, particularly timeouts, 429s and successful responses carrying error bodies · the aggregation method, since minute-buckets and request-weighted ratios diverge sharply during a short total outage · whether the incident was inside an announced maintenance window · and the process fix, which is a shared dashboard computed from an agreed definition so the next month is not an archaeology exercise.

Quick check

Quiz: Why is the percentage rarely the disputed part of an SLA? Because the argument is almost always about whether a period counted as downtime, which is decided by the measurement point, the error definition and the aggregation window.

Flashcard: Which SLA definition catches partial degradation that availability targets miss? — Counting successful-looking responses that carry error bodies, and bucketing by time rather than weighting by request volume.