Failover Simulator

Set a failure rate for every hop in a fallback chain and read the exact traffic split, latency and cost it produces.

Primary failure rateThe one control. Drag it and watch availability barely move while latency and cost do not.

12%

Second hop failure ratepercent of the calls it receives

Third hop failure ratepercent of the calls it receives

Primary latencymilliseconds, successful call

Second hop latency

Third hop latency

Time wasted before each failoveryour timeout, or how long a failing call hangs before you give up

Primary costyour rate, per 1,000 successful requests

$ / 1k

Second hop costper 1,000 successful requests

$ / 1k

Third hop costper 1,000 successful requests

$ / 1k

Availability your callers see

99.9904%

96 requests per million fail everywhere — about 4.02 nines.

Where a million requests end up. Each band is the share of traffic finally served by that hop; the red tail is the share no hop served.

served by primary
served by second
served by third
not served at all

Served by the primary: 88.000%
Served by the second hop: 11.520%
Served by the third hop: 0.470%
Served by nothing: 0.0096%
Mean latency, successful requests: 1,088 ms
Mean latency, counting failures: 1,088 ms
Latency the primary alone would give: 800 ms
Cost per 1,000 requests: $3.26
Cost if the primary never failed: $3.00
Cost premium the chain is paying: 8.6%

What this assumes: every hop is tried in order and independently — one hop failing tells you nothing about the next, which is exactly what a shared region, a shared upstream or a correlated capacity crunch breaks. A failed attempt burns the full timeout you entered and is not billed, so cost counts successful calls only; if your provider bills partial streams, add that separately. Latency is a mean over the whole population, not a p99 — the tail is worse than the number above, because the slow requests are precisely the ones that took two extra timeouts.

A fallback chain is a multiplier, not a fix. If the primary drops 12% of calls and the second drops 4% of what it receives, the share that reaches neither is 12% × 4% × whatever the third drops — which is why the availability figure at the top stays reassuring long after the system underneath has stopped being healthy. That is the useful thing to see: drag the primary from 1% to 40% and the headline barely moves.

What moves is everything else. Each failover costs a timeout before it starts, so mean latency climbs in steps of whatever you set that timeout to, and every request the primary sheds gets served by a hop you priced differently. The cost premium row is the one that finds real outages: a chain absorbing a bad afternoon shows up as a bill that is 30% higher than the day before, days before anyone reads a dashboard. Alert on the share of traffic served by the primary, not on the error rate, and you get the same warning while it is still cheap.

What this leaves out is correlation, and it is the big one. The independence assumption is what turns three mediocre providers into four nines on paper. Real chains fail together — one region, one upstream model host, one expired certificate — and when they do, the multiplication above stops applying and the true availability is closer to the worst single hop than to the product. Treat the number as the best case your topology allows, then ask what the three hops share.

Failover Simulator

The reasoning behind this

Related tools