List the components a request depends on and how many redundant copies each has. The calculator multiplies them into the availability your users actually get.
Each row is one dependency in the request path. "Replicas" is how many independent copies can each serve the request on their own.
Runs entirely in your browser — nothing you enter here is sent to a server.
Every dependency in the path of a request can take the request down, so availabilities in series multiply. Four services at 99.9% each give 0.999⁴ = 99.6%: about 2 hours 55 minutes of downtime a month instead of the 43 minutes each provider promised. The more dependencies, the lower the ceiling — and no amount of care in your own code raises it.
Redundancy works the other way. If two independent replicas can each serve the request, both have to fail at once: 1 − (1 − 0.999)² = 99.9999%. That is why a pair of ordinary servers behind a load balancer beats one excellent server.
A = A₁ × A₂ × … × Aₙ. The result is always lower than the weakest component.
A = 1 − (1 − Aᵢ)ⁿ. Each extra independent replica multiplies the failure probability by the single-copy failure rate.
The parallel formula assumes failures are unrelated. Two replicas in one zone, on one database or behind one bad deploy fail together.
DNS, CDN, TLS certificates, the auth provider and third-party APIs are all in the chain, even if they are not on your architecture diagram.
If the composite figure is below the SLA you want to offer, you have three levers: make a critical dependency redundant, remove it from the critical path (cache, queue, graceful degradation), or promise less. The table shows which component costs you the most downtime — start there.
Multiply their availabilities as decimals. Three services at 99.9%, 99.95% and 99.99% give 0.999 × 0.9995 × 0.9999 = 99.84%.
Only with redundancy across independent failure domains, such as multiple zones or regions. A single instance cannot be more available than the platform it runs on.
In theory yes, if failures are independent. In practice shared causes — a bad release, a common database, the same region — make the gain smaller, so treat the number as an upper bound.
No. Include only components whose failure makes the request fail. If the page still works when recommendations or analytics are down, they are not in the critical path.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.