A 99.9% SLA: the outage hiding inside a healthy headline

The overall indicator is green while one payment method works for nobody. Even a correctly calculated availability figure can hide this: a low-volume method barely moves the aggregate. A useful SLA explains whose experience the percentage measures, which events count and what the team does before the month is over.

Find the customers hidden by the denominator

Imagine 100,000 eligible requests in a measurement window. The main method produces 99,900 technically successful results. A second method receives 100 requests, all ending in technical errors. Aggregate availability is 99.9%; availability for the second method is 0%. This is a separate hypothetical illustration, not a provider performance report.

The report can follow its overall formula precisely and still be insufficient for the business. Name critical segments beforehand: payment method, country, currency or a particular route. For small samples, show affected counts and sequences of failures. A percentage with several decimal places can imply more precision than the evidence deserves.

Avoid creating hundreds of ownerless slices. Choose segments that lead to genuinely different decisions: inspecting an integration, briefing support or changing the offered customer flow within permitted limits. Each indicator needs an audience that knows what to do with it.

Separate the indicator, target, and agreement

An SLI is the measured indicator, an SLO is its target, and an SLA sets the agreement and consequences of missing it. Google SRE also emphasizes latency distributions because averages can conceal a small proportion of very slow responses. Source: Google SRE, Service Level Objectives.

For a payment integration, describe three intervals separately: request submission to API response; operation creation to the chosen final status; and event creation to receipt of the notification by your system. Each interval has different failure modes. Time spent by a customer approving a payment in their banking app should also be distinguished from infrastructure processing time.

Availability needs a denominator too

A time-based 99.9% target over an illustrative 30-day period corresponds to 43.2 minutes of unavailability when the entire period is included without exclusions. A request-based target means something different: among 100,000 eligible requests, the error budget is 100 unsuccessful requests. You cannot convert between these definitions without traffic information. Ten peak-time minutes may affect more payments than an hour overnight.

The Google SRE Workbook recommends expressing many indicators as good events divided by total eligible events. This makes the numerator, denominator, and relevant threshold explicit. Source: Google SRE Workbook, Implementing SLOs.

A correctly processed issuer decline may count as a successful technical response. It does not count as a successful payment for conversion analysis. Keep both measures visible. Agree on timeout treatment as well: if slow requests disappear from the latency sample when they time out, the latency chart can look better during an outage.

A low average can hide a painful tail

Consider 1,000 hypothetical requests. Of these, 980 finish in 0.2 seconds and 20 take 10 seconds. The average is 0.396 seconds. That looks comfortable, although twenty customers experienced a substantial wait. Using the nearest-rank calculation, p95 is 0.2 seconds and p99 is 10 seconds.

The p99 value marks a boundary for approximately 99% of observations in the selected sample. It is neither the maximum nor a guarantee for the next request. Display the sample size and measurement window alongside it. High percentiles are unstable for low-volume payment methods; the absolute count of slow operations can be more informative there.

Do not average individual server or daily p99 values to obtain a combined p99. Prometheus explicitly warns against aggregating precomputed quantiles this way. Histograms allow distributions to be combined when their structural requirements are respected. Source: Prometheus, Histograms and summaries.

A contractual month is too long for the on-call operator

Separate agreement reporting from immediate investigation signals. A monthly figure supports contractual assessment. Operators need recent errors, pending-payment counts and the age of the oldest unknown outcome. Set internal thresholds using your observations and tolerance for harm rather than presenting an invented universal threshold as an industry standard.

For provider escalation, retain redacted references, an exact window with timezone, expected results, actual codes and the affected traffic volume. Explain how the examples were selected. Five failed payments can support diagnosis but cannot establish incident scale without the total number considered.

Define the response to missing telemetry separately. If a counter stops updating, zero recorded errors do not establish recovery. Compare independent logs and operational queues. Close the incident after confirming that the required customer step works again and that accumulated unknown outcomes have been addressed. A healthy API does not by itself explain what happened to requests during the failure. Keeping these conditions separate prevents a fast technical recovery from hiding an unfinished operational clean-up.

What to establish before agreeing to the SLA

• The operation and measurement boundaries: API, payment method, region, and relevant outcome.
• The calculation window, timezone, data source, and minimum sample size.
• The handling of errors, timeouts, retries, and excluded events.
• Latency and availability targets aligned with the actual business process.
• Notification, escalation, evidence, and breach-review procedures.

Keep a customer-impact measure even when the contract excludes some causes of failure. Customers still wait when an external participant has a problem. Contractual responsibility and operational diagnosis need different views, and both are useful.

For example, a healthy API response metric alongside worsening final-status times suggests a different investigation from delayed notifications alone. The first may require checking processing stages and upstream dependencies. The second may require examining delivery queues, receiving endpoints, or your own event handling. A single availability number cannot distinguish them.

At the next review, take the worst-affected method and reconstruct its path from request to customer outcome. Compare that path with what the SLA actually covers. The gap identifies which observation or agreement term needs clarification first.