Your Uptime Is Not Your Uptime: Availability Across a Dependency Chain

If a request has to pass through ten services to succeed, and each of them is independently available 99.9% of the time, the request succeeds 99.0% of the time. Not 99.9%. The arithmetic is one line, 0.999 raised to the tenth power, and it produces 0.99004, which is 87.2 hours of failure per year instead of the 8.8 hours a single 99.9% service would imply.

Most teams have never run this calculation for their own stack, and the reason is understandable. Each vendor is evaluated on its own during procurement, each one clears the bar, and nobody composes the results. The composition is where the number lives.

This article covers how availability composes in series and in parallel, why the independence assumption behind redundancy is usually wrong, and how to get a defensible figure for your own service. It is aimed at platform and SRE teams who have to publish an availability target and would prefer it to survive contact with a quarter of real data. If you need the definitions first, SLA vs SLO vs SLI covers those, and how to calculate uptime percentage covers the single-service case.

A series dependency is one where failure propagates: if the component is down, your request fails. Authentication, the primary database, the payment processor on a checkout path, the DNS provider resolving your own domain. For these, availabilities multiply, so adding a dependency can only lower the result.

The decline is gentle at first and then not. Three vendors at 99.9% still give you 99.7%, which sounds fine until you convert it to 26 hours a year. Ten gives you 99.0%. Thirty, which is an unremarkable number of external services for a mature SaaS product, gives you 97.0% and 259 hours. That is more than ten full days.

Two things soften this in practice, and it is worth knowing which of them you actually have. The first is that not every dependency is on every path, so a failure in your analytics provider does not fail a checkout. The second is that some failures are absorbed by retries, caches, or queues. Neither applies automatically. They apply if you built them, and the honest exercise is to work out which of your dependencies are genuinely in series for each critical user journey and compute per journey.

Put two components in parallel, where either one succeeding is enough, and unavailability multiplies instead of availability. Two independent services at 99.9% each give a combined 99.9999%, because both must fail simultaneously and that is one in a million. The formula is one minus the product of the failure probabilities.

That result is real and it is also the most over-claimed number in infrastructure planning, because it holds only when the failures are independent. Two database replicas in the same availability zone are not independent. Two CDN providers whose edge nodes both depend on the same DNS root are correlated. Two SaaS tools that both run on the same cloud region fail together whenever that region does, and you will discover this at the same moment as everyone else.

Correlation does not have to be total to destroy the benefit. If two components fail together only 10% of the time they fail at all, your effective combined availability collapses from six nines toward the correlated floor, which is roughly the availability of the shared dependency underneath. The practical rule is that a redundant pair is worth about as much as the least independent thing they share. Working out what they share is covered in cloud concentration risk.

A second trap is that failover itself has an availability. If your secondary is healthy but the mechanism that switches to it fails half the time, you have not built a parallel system. You have built a series dependency on your failover logic and attached a spare to it.

Work one critical user journey at a time. Checkout, sign-in, and whatever your product's core verb is. For each, list only the external services that must succeed for the journey to succeed, which is usually a much shorter list than your total vendor count and is the part people get wrong in the reassuring direction.

Take each vendor's contracted availability, then adjust it for what the contract excludes. Scheduled maintenance is almost always carved out, and a 99.9% commitment with a four-hour monthly maintenance allowance has an effective ceiling nearer 99.34%. Use the adjusted figure, because that is what your users experience.

Multiply. The result is your ceiling: the best you could do if your own code were perfect and never shipped a bug. Then subtract your own failure rate, which for most teams is larger than the vendor contribution and is the part you can actually fix.

Publish a target below the ceiling, with room. A target equal to your ceiling assumes you never cause an outage yourself, which no team achieves. The gap between ceiling and target is the only budget you genuinely control, and error budgets for third-party downtime covers how to spend it.

Contracted availability is a commercial term and a poor predictor. Vendors routinely exceed their SLAs, because the SLA is set at a level they are confident of meeting with remedies attached, and vendors occasionally fall far short. Either way the contract tells you about the vendor's risk appetite and not about last quarter.

Measured availability per vendor, over a window long enough to include their bad month, is what belongs in this calculation. Ninety days is a reasonable minimum and a year is better, since incidents cluster and a clean quarter proves less than it feels like it does.

The measurement also lets you check the independence assumption instead of asserting it. Line up incident timelines across your vendors and look for overlap. Two providers whose degradations repeatedly coincide within the same hour are telling you something about a shared dependency that no architecture diagram shows, and that correlation is the input your redundancy planning actually needs.

How do I calculate combined availability for services in series? Multiply the individual availabilities as decimals. Three services at 0.999 give 0.999 times 0.999 times 0.999, which is 0.997003, or 99.7%. Convert to downtime by multiplying the complement by the hours in your period: 0.002997 times 8,760 is about 26 hours a year.

Does adding a vendor always reduce availability? In series, yes, because you are multiplying by a number below one. In parallel it increases availability, but only to the extent that the two components fail independently. Most parallel pairs share something, and the shared component sets the real ceiling.

Why does my measured uptime look better than this math predicts? Usually because not every dependency sits on every path, because retries and caches absorb short failures, or because your measurement window has not yet included a bad month. Check the window length before concluding the model is pessimistic.

Should I use contracted or measured availability? Measured, for planning. Contracted, for contracts. The contracted figure tells you what remedy you can claim; the measured figure tells you what your users will experience, and only one of those belongs in a capacity or reliability model.

How many nines should I promise customers? Fewer than your computed ceiling, with enough margin to absorb your own incidents. If your dependency chain caps you at 99.5%, promising 99.9% guarantees you will owe credits for failures you cannot prevent, which is an expensive way to discover arithmetic.