Failover Readiness, kpi

​

At a glance

A yes / no readiness verdict: if the primary died this second, is there a healthy standby that could be promoted with near-zero data loss? Readiness is true only when at least one standby is connected, streaming, caught up (lag under one second), and confirmed receiving WAL. This is the card a platform team glances at before every risky deploy, every maintenance window, and every time the pager goes quiet for too long. A green primary with no promotable standby is a single point of failure dressed up as high availability.

​

Calculation

1. LSN distance: pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) on the primary gives the byte gap between what the primary has written and what the standby has replayed. Converted to a time estimate using recent apply throughput.
2. Time-based: pg_last_xact_replay_timestamp() on the standby compared against the current time gives the wall-clock age of the last replayed transaction. This is the figure used for the one-second threshold because it is the closest proxy for “how much committed data would we lose if we promoted right now”.

• Ready when at least one synchronous or low-lag asynchronous standby meets every criterion.
• Not ready when no standby qualifies: none connected, the only standby is in catchup, lag exceeds one second, or WAL receipt has stalled.

​

Worked example

What the DBA reads from this:
  - Local HA is intact: a primary failure now still promotes db-standby-a
    with ~0.4s of exposure. The migration can continue.
  - DR is temporarily degraded: a simultaneous loss of BOTH the primary and
    the local standby would force promotion of a 47s-behind copy = up to
    47s of committed orders lost. Low probability, but worth noting.
  - Action: let the migration finish, then confirm db-standby-b catches back
    up below 1s before declaring the maintenance window closed.

1. A healthy primary tells you nothing about failover safety. The whole point of this card is that the primary can be perfectly green while you have zero ability to recover from its loss. Read readiness independently of primary health.
2. Lag is the data-loss meter. The one-second threshold is a proxy for RPO. A standby 47 seconds behind means promoting it loses up to 47 seconds of committed transactions. For strict zero-loss requirements, only a synchronous standby counts.
3. Standbys fail silently. A standby can drop into catchup, stall on WAL receipt, or fall behind a slow link without anyone noticing, because nothing user-facing breaks until you actually need it. Continuous readiness monitoring is the only reliable way to know.

​

Sibling cards

​

Reconciling against the source

On the primary: SELECT application_name, state, sync_state, replay_lag, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS bytes_behind FROM pg_stat_replication; shows every connected standby, its state, and how far behind it is. On the standby: SELECT pg_is_in_recovery(); should return true, and SELECT now() - pg_last_xact_replay_timestamp() AS replay_age; gives the wall-clock lag that the one-second threshold compares against. WAL receipt confirmation: SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(); on the standby; if receive is advancing but replay is stuck, the standby is receiving but not applying. Managed HA: the RDS / Aurora console shows the Multi-AZ standby and replica lag under the instance detail; Cloud SQL shows the HA failover replica health on the instance overview.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre