Composite Availability Calculator
Calculate the compound availability of a service that depends on multiple upstream services. Model serial dependency chains and redundant copies. See the worst offender and what it would take to hit your SLA target.
Dependencies
| Name | Availability | Redundancy | Effective | |
|---|---|---|---|---|
% | 99.950% | |||
% | 99.900% | |||
% | 99.990% | |||
% | 99.990% | |||
% | 99.500% |
Compound availability
99.3309%
Worst offender
Feature-flag service (99.500%) is dragging your compound availability down the most.
Removing or fully eliminating this dependency would lift compound availability from 99.3309% to 99.8301% — a gain of 0.4992%.
In practice you usually cannot remove a dependency. Options: add redundancy (set the column above to 2× or 3×), build a fallback that lets you degrade gracefully when it's down, or push for a stronger SLA from the upstream provider.
Automate your incident response
Reduce MTTR by 90% with AI-powered root cause analysis. Free to start.
The hidden cost of every new dependency
It is one of the most surprising results in reliability engineering: even if every individual service in your stack is "three nines or better," your real SLA ceiling can be dramatically lower. A service that depends on five upstream services each at 99.9% has a compound availability of about 99.5% — roughly 44 hours of allowed downtime per year, not 8 hours 45 minutes.
This is not a bug in the math. It is the math. Availability multiplies in series, and the more you stack, the worse the compound number gets. Tools like this one make the cost visible — which usually changes the architecture conversation.
When redundancy helps and when it doesn't
Redundancy is the standard answer: if one copy is at 99%, two independent copies are at 99.99%. The word doing the work is "independent." In practice, redundancy fails when failures are correlated:
- Two replicas in the same availability zone share zone-level outages
- Multi-region deploys still share the same control plane, the same DNS, the same shared upstream (Stripe, Auth0, etc.)
- Same code on every replica means the same bug brings them down at the same time
- Shared identity provider, shared CI/CD pipeline, shared deploy script — all create correlation
For the calculator above, set redundancy 2× or 3× when failures are genuinely independent. For correlated failure modes, model the shared upstream as a separate row.
Graceful degradation: the third option
The most powerful technique is often to make a dependency optional. If your feature-flag service goes down and the application defaults to the last-known-good values, that dependency does not multiply into your availability. The rule of thumb: design every dependency call site with an explicit answer to "what should we do if this is unavailable?". Often the answer is "use a cached value," "return a sensible default," or "skip the step." Each of those moves the dependency off your critical path.
Why dependency-aware reasoning matters in incidents
Knowing your dependency graph is half of fast incident response. When a symptom appears in your service, the actual root cause is often upstream — and identifying which upstream is what slows down most investigations. Uptimes.ai builds and continuously updates a real-time service dependency graph from eBPF kernel data, then uses it during automated root cause analysis to follow the failure backwards through your stack. The same graph you mapped out in this calculator is what our AI SRE agent reasons over during a real incident.