HA Failover Budget Calculator

Failover path visual unavailable

Starter profile:

Choose a starting architecture or keep the current values.

Service name:

Use a short workload, cluster, or HA-pair label.

Health-check interval:

Use the configured monitor, load-balancer, cluster-manager, or VRRP probe cadence.

sec

Failed checks:

Enter a whole threshold from 1 to 100 checks.

checks

Promotion and fencing:

Measure until the replacement side is safe to become active.

sec

State catch-up:

Use zero only for a stateless or already-synchronous path.

sec

Traffic convergence:

Measure until new traffic reaches the promoted side.

sec

Client retry or cache tail:

Use client-side evidence when this tail outlasts the server-side transition.

sec

Ready validation:

Count only checks required before the service meets its recovery definition.

sec

RTO target:

Use zero only when exploring phase timing without a committed target.

sec

Detection jitter allowance:

Zero leaves the base probe cadence unchanged.

sec

Manual approval delay:

Zero represents a fully automated failover path.

sec

Replication lag at failover:

Zero represents synchronous, stateless, or separately measured freshness.

sec

RTO safety buffer:

A 10% buffer requires the modeled path to fit within 90% of the RTO for a comfortable result.

{{ row.label }} {{ row.value }} {{ row.note }}

Phase	Duration	Elapsed	Share	Planning note	Copy
{{ row.label }}	{{ row.duration }}	{{ row.elapsed }}	{{ row.share }}	{{ row.note }}

A service is not recovered merely because a standby process has started. Users may still wait for failure detection, fencing or promotion, state catch-up, routing changes, stale client connections, and a final readiness check. The slowest visible symptom can sit outside the cluster itself, especially when client retries or cached endpoints outlast the server transition.

A failover budget turns that recovery path into a time allowance. It helps teams compare an observed or planned sequence with the recovery time objective (RTO), which is the maximum acceptable delay between interruption and restored service. That target should come from business impact and dependency needs, not from whichever number the current architecture happens to achieve.

RTO: The maximum acceptable service-recovery delay.
Recovery point objective (RPO): The maximum acceptable loss or staleness of data. Replication lag is an RPO clue, not a duration automatically added to RTO.
Recovery definition: The observable condition that ends the outage, such as a successful client transaction rather than a process reporting healthy.
Safety reserve: Part of the RTO deliberately left unused for jitter, variation, and unmodeled delay.

The phases do not always run one after another. Promotion, state replay, routing, and client recovery can overlap, so a serial sum is a conservative planning model only when the entered measurements represent non-overlapping intervals. If timings come from different incidents or different definitions of “ready,” their total can look precise without being comparable.

A budget is most useful before and after a controlled exercise. Beforehand it shows where the target has been allocated. Afterwards it provides a structure for replacing assumptions with timestamps from monitoring, cluster logs, routing evidence, and client-side checks.

How to Use This Tool:

Choose one workload and one recovery definition, then enter durations measured against that same event boundary.

Select a Starter profile or keep the current values, and give the service a short label.
Enter the health-check interval and whole failed-check threshold. Add detection jitter only for delay not already represented by those probes.
Enter promotion, catch-up, traffic convergence, client tail, validation, and manual approval durations. Use zero only when a phase genuinely does not block recovery.
Set the RTO target and optional reserve percentage. An RTO of zero is allowed for timing exploration, but it cannot produce a pass decision.
Compare the RTO decision with the phase ledger, then validate the longest phase in a controlled failover test.

Interpreting Results:

RTO clears with reserve means total modeled time is less than or equal to the RTO after its reserve is removed. RTO clears; reserve consumed still meets the full RTO, but the planned cushion has been used. RTO at risk means total time is greater than the RTO. Equality belongs to the passing side for both limits.

The named Longest phase is the first phase with the largest entered duration. Tune it first only after confirming that the measurement is reliable and not overlapping another phase. A passing model is not proof of recoverability; repeat the exercise from a real client path and include dependencies that determine when service is genuinely ready.

Technical Details:

The model treats recovery as seven serial phases. Failure detection is derived from probe cadence, while the remaining durations are entered directly. This makes the result easy to audit, but it also makes phase boundaries and overlap assumptions part of the model.

Formula Core

Detection time is the configured probe interval multiplied by the number of failed checks, plus a separate jitter allowance:

t_{detect} = t_{check} \times n + t_{jitter}

Total recovery time is the sum of detection, promotion and fencing, state catch-up, traffic convergence, client retry or cache tail, ready validation, and manual approval:

t_{total} = \sum_{i = 1}^{7} t_{i}

The reserve and comfort target are computed from the RTO and reserve percentage:

t_{reserve} = t_{RTO} \times \frac{p}{100}, t_{comfort} = t_{RTO} - t_{reserve}

RTO margin is RTO minus total time; comfort margin is the comfort target minus total time; utilization is total time divided by RTO × 100%. Computation keeps full numeric precision, while the interface formats durations for reading.

Rule Core

Exact failover-budget decision rules
Condition	Decision
RTO = 0 seconds	RTO target not set; no pass or comfortable-pass state is produced.
Total ≤ comfort target	RTO clears with reserve.
Comfort target < total ≤ RTO	RTO clears; reserve consumed.
Total > RTO	RTO at risk.

Health-check interval accepts 0.1 to 3,600 seconds and failed checks accepts whole values from 1 to 100. Each entered phase accepts 0 to 86,400 seconds; RTO accepts 0 to 604,800 seconds; reserve accepts 0% to 80%. All boundaries are inclusive.

Replication lag at failover is reported as data-loss context but is not added to state catch-up or total recovery time. Enter the actual catch-up duration separately. This distinction prevents a five-second lag observation from being treated automatically as five seconds of outage.

Accuracy Notes:

The serial sum can overstate recovery time when phases overlap and understate it when dependencies, queue drain, DNS caches, connection pools, application warmup, or human escalation are missing. RTO and RPO must be defined for the workload and its business impact. Replace profile values with evidence from controlled exercises, use consistent start and end timestamps, and do not test production failover without an approved runbook, rollback path, capacity check, and stakeholder window.

Worked Examples:

Database path with a tight reserve

A 5-second probe repeated three times plus 3 seconds of jitter yields 18 seconds of detection. Adding 35 seconds for promotion, 20 for catch-up, 10 for convergence, 15 for the client tail, and 20 for validation gives 118 seconds. Against a 120-second RTO with a 10% reserve, the comfort target is 108 seconds. The path meets the full RTO by 2 seconds but consumes the reserve by 10 seconds, and promotion is the longest phase.

References:

Define recovery objectives for downtime and data loss, AWS Well-Architected Framework.
SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, National Institute of Standards and Technology, November 2010.
How to run a Pacemaker failover test with PCS, Simplified Guide.
How to run a PostgreSQL failover test in Pacemaker, Simplified Guide.