SLI Measurement Point

An availability objective is a number about requests, and requests can be counted in several places: inside the process that served them, at the load balancer that routed them, in the client that issued them, or by a probe that imitates them. The places disagree, and they disagree most during the failures the objective exists to catch.

The disagreement is not noise. A process that has crashed, deadlocked or stopped accepting connections emits nothing, so an indicator computed from in-process metrics has no denominator and no numerator for the worst minutes of the worst incident. "No data" is then read as "no errors", and the objective reports health through an outage.

Choosing the measurement point is therefore not an implementation detail of the SLO. It is the decision that fixes which class of failures the SLO is capable of noticing.

Why it matters

The budget arithmetic needs resolution the vantage point must supply. A 99.9% monthly objective allows about 43 minutes of unavailability in 43,200, so the measurement must resolve single minutes. Real traffic at the edge gives millions of samples; a synthetic probe at one per minute gives 43,200, and a genuine four-minute outage is four data points.

It also decides what conversations are possible. When engineering measures at the server and support measures at the client, the two numbers differ, both are honest, and the disagreement surfaces during the incident review rather than before it.

Implementation patterns

• Default to the outermost component you control, usually the load balancer or API gateway, because it records requests that no backend ever saw — connection refusals, 503s generated by the balancer itself, requests arriving when every instance was unhealthy.
• For internal traffic over a mesh, measure at the caller's sidecar. There is no shared edge, so the client-side proxy is the outermost point under your control, and it sees connection failures the server cannot.
• For asynchronous or batch flows, measure outcomes, not requests. There is no HTTP response to count; the indicator is "did the effect happen within the deadline", read from the business store.
• Keep client telemetry as a mandatory secondary. It is the only source that sees failures between your edge and the user, and it must not be the primary because it arrives late, is missing for users who could not start the app, and is not under your control.
• State the measurement point in the SLO document itself, alongside the target and the window. An objective without a stated vantage point is not reproducible.

Industry example

Google's SRE practice, which popularised service level objectives, is explicit that indicators should be measured as close to the user as is practical while remaining under the service owner's control, and that server-side metrics are chosen for availability precisely because they capture requests the application did not handle. The same reasoning is why edge and gateway access logs, rather than application metrics, are the usual source in large estates: the balancer is the last component in the path where a failed request still exists as a record.

Failure scenarios

• The invisible outage: every instance is down, nothing is emitted, the SLI reads 100% for the duration.
• The flattering denominator: an instance that is failing stops serving, so its errors leave the numerator and the aggregate improves during degradation.
• Probe-only objectives: the service is broken for one tenant's traffic shape and the probe, which exercises one path, is green throughout.
• Client-only objectives: a bad app release makes the number collapse, and there is no way to tell whether the backend was involved.
• Two teams, two vantage points, one argument, conducted during the incident.

Trade-offs

When not to use it

Do not compute one objective from several sources and reconcile them. An error budget that can be derived three ways will be litigated in the week it is being spent. One source is the objective; the others are diagnostics. And for a service with genuinely low request volume — a few thousand a day — a ratio-based SLI at any vantage point is noise, and the honest instrument is a count of bad events with a documented threshold.

Interview question

Q: Your checkout service reports 99.97% availability from application metrics. Support reports three multi-minute outages last month. Both are telling the truth. Explain how, and tell me what you would change.

What a strong answer covers: that a process which cannot respond emits nothing, so the worst minutes are absent from both numerator and denominator; that absence is being read as success; the move to edge access logs as the primary source with client telemetry as a mandatory secondary; and the point that the SLO document must name the vantage point or the number is not reproducible.

Quick check

Quiz: Why are in-process metrics the wrong primary source for an availability SLI? Because they cannot record requests the process never handled, which is exactly the set of requests that a total outage consists of.

Flashcard: Where should an availability SLI be computed? At the outermost component you control that sees every request — usually the load balancer — because it is the last place a failed request still exists as a record; client telemetry is a mandatory secondary, never the primary.