A service reports 99.9% availability per request and the team is pleased. A typical user session makes about 150 requests. Roughly what share of sessions see at least one error, and why does that number matter more than the SLO?

The arithmetic

If each request independently succeeds with probability 0.999, a session of 150 requests succeeds entirely with probability 0.999^150. That is about 0.86, so roughly 1 session in 7 — about 14% — sees at least one error.

The general form is worth memorising: for a small error rate e and n requests, the chance a session sees at least one error is approximately n × e. 150 requests at 0.1% is about 15%. The approximation holds well while n × e stays below roughly 0.3.

Why the session number matters more

Because a user experiences sessions, not requests. "99.9% available" sounds like one user in a thousand having a problem; the reality is one session in seven. That gap is the single most common reason a team's SLO is green while customer satisfaction is not, and it is arithmetic rather than measurement error.

It also changes what you must fix. Reducing the per-request error rate and reducing the number of requests per session are equally effective, and the second is often far cheaper: a page that makes 40 calls instead of 150 improves user-visible reliability by the same factor as a threefold improvement in service reliability.

And it reframes retries. A retry that succeeds converts a request failure into added latency rather than a session failure, which is why client-side retry with jitter is one of the cheapest reliability improvements available — it operates directly on the exponent.

What to do with it

• State the request count per journey alongside any availability target. Without it, the target cannot be translated into user experience.
• Set the SLO on the journey where you can. "Checkout completes" is measurable and is what the business cares about; per-request availability is an input to it.
• Count the chain, not just your service. If a journey crosses 4 services each at 99.9%, the per-request figure for the journey is already about 99.6% before session length is considered.
• Attack the exponent first. Fewer calls per journey, idempotent operations so retries are safe, and client retries with jitter.

When this is the wrong framing

When requests are not independent and not equally important. A session making 150 calls where 149 are background telemetry and 1 is the payment has a user-visible reliability determined almost entirely by the one. Multiplying blindly over-states the problem.

The fix is to weight: identify the critical requests in the journey and compute over those. A journey-level SLI built from the handful of requests the user would notice failing is more useful than either the raw per-request number or a naive exponent.

Common weak answers

• "99.9% means 0.1% of users have a problem." This is the error the question exists to correct, and it is extremely common in SLO reviews.
• "Add retries." Correct and incomplete. Retries only help for idempotent operations, they consume the same capacity as first attempts, and without a retry budget they turn a partial outage into a full one.
• "Raise the SLO to 99.99%." Ten times the engineering cost to take sessions from 14% to about 1.5% affected. Reducing calls per journey may achieve the same for a fraction of the effort, and the comparison should be made explicitly.