A checkout API has a 99.9% availability SLO and the team must decide where the indicator is computed from. The candidates are load-balancer access logs, in-process server metrics, the mobile client's own reporting, and synthetic probes. Which should be the primary source?
Show the full answer Hide the answer
The deciding property
An availability SLI must be computed at the outermost point you control that sees every request, including the ones no backend ever handled. That single property settles the choice, because the failures an availability objective exists to capture — every instance unhealthy, connections refused during a bad deploy, the gateway itself returning 503 — are precisely the ones where the service emits nothing at all.
Why the load balancer wins
The access log is generated by the component that terminated the connection. It records the request whether a backend answered it, answered it slowly, or was never reached. It is the last place in the path where a failed request still exists as a record.
It also has the volume the arithmetic needs. A 99.9% monthly objective allows about 43 minutes of unavailability in 30 days, so the measurement has to resolve minutes out of 43,200. Real traffic gives millions of samples; anything with fewer cannot see the budget being spent.
Why the other options fail
- In-process server metrics are the most precise account of work the process did, and they are blind exactly when it matters. A process that has crashed, is deadlocked, or is refusing connections reports nothing — and "no data" is read by most systems as "no errors". This is the option that looks most rigorous and quietly excludes the worst outages from the numerator.
- Mobile client telemetry is the truest measure of experience and the wrong primary source. It is not under your control, it arrives minutes to hours late through batched uploads, it is structurally missing for users whose app could not start, and it blends your failures with the user's own network. Keep it as a secondary signal that catches what the server-side view cannot — but an objective you cannot compute during an incident is not an operational objective.
- Synthetic probes have a fixed, tiny sample rate. At one probe a minute you get 43,200 samples a month, so a single failed probe moves the number by 0.002% and a genuine four-minute outage may produce four data points. They also exercise one synthetic path, never the tenant, payload and cache mix that real failures depend on. Probes answer "is it reachable from Frankfurt right now", which is a useful and different question.
What would flip the decision
| If this changes | Measure from | Because |
|---|---|---|
| The service is internal and called only over a mesh | The caller's sidecar | There is no shared edge; the client-side proxy is the outermost point you control |
| The user-visible failure is in the browser or app | Client telemetry, with the edge as secondary | Server-side success and a blank screen are compatible states |
| The objective is on a batch or asynchronous flow | Outcome records in the business store | There is no request to count; completion within a deadline is the indicator |
Common weak answers
"Use all four and average them" is not an SLO; it is a dashboard. One source is the objective and the others are diagnostics, because an error budget that can be computed three ways will be argued about during the one week it is being spent.