Decide which lag matters
PostgreSQL replication lag is not one number. A standby can lag in receiving WAL, writing or flushing WAL, or replaying WAL into query-visible state. The operational question determines the useful measurement: are bytes still in transit, is disk replay behind, or has a standby stopped progressing entirely?
Before interpreting any lag value, identify whether the topology is physical streaming replication, archive recovery, synchronous replication or logical replication. A primary-side value does not replace an independent standby-side check.
Query primary-side replication state
On the primary, a suitably authorized monitoring account can inspect pg_stat_replication. Common fields include application_name, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn, and version-dependent lag intervals.
SELECT application_name, client_addr, state, sync_state,
sent_lsn, write_lsn, flush_lsn, replay_lsn,
write_lag, flush_lag, replay_lag
FROM pg_stat_replication;A missing row means the primary does not currently report a connected WAL sender for that standby; it does not automatically prove data loss. Client addresses and application names may be confidential, so redact diagnostic exports.
The reported write_lag, flush_lag and replay_lag fields are not guaranteed to represent a continuously increasing real-time backlog. PostgreSQL documentation describes limitations and conditions for these interval estimates; avoid translating a null interval into zero lag.
Inspect the standby directly
On a physical standby, verify whether it is in recovery and how far replay has advanced:
SELECT pg_is_in_recovery(),
pg_last_wal_receive_lsn(),
pg_last_wal_replay_lsn(),
pg_last_xact_replay_timestamp();The difference between the current clock and pg_last_xact_replay_timestamp() is often cited as "lag," but it can be misleading on an idle primary: when no transactions occur, the replay timestamp may become old even if the standby is caught up. Compare LSN progress and actual workload before declaring a replication failure.
Use pg_stat_wal_receiver where available to review the active receiver and upstream connection. Check network links, disk I/O, replay conflicts, WAL retention capacity and restart history.
Verify risk and recovery objectives
Define two distinct objectives: acceptable loss in a failover (RPO) and acceptable restoration time (RTO). Replication health contributes to RPO but does not by itself demonstrate failover readiness. Periodically validate backups and controlled failover procedures in an isolated environment.
Alert on stalled LSN progress, disconnected replication, disk/WAL pressure and excessive backlog relative to documented thresholds. For the report, store version, primary/standby role, sample time and all assumptions. Never expose passwords or connection strings.