Replication Monitoring
Monitor replication lag, replica status, and replication slots.
The Replication page tracks the state of your database replicas and replication lag over time.
Overview
The current replication state shows:
| Field | Description |
|---|---|
| Is replica | Whether this instance is a standby/replica |
| Replication lag (bytes) | How far behind the replica is in WAL bytes |
| Replication lag (seconds) | Estimated time delay between primary and replica |
| Upstream host | The primary server this replica streams from |
Replication Slots
For PostgreSQL, each replication slot shows:
| Field | Description |
|---|---|
| Slot name | Name of the replication slot |
| Slot type | physical or logical |
| Active | Whether a consumer is connected |
| Lag (bytes) | How much WAL the slot is retaining |
Inactive slots with growing lag can cause WAL accumulation and disk pressure on the primary. Monitor the lag and drop unused slots.
Lag History
The lag history chart plots replication lag over time. Use this to:
- Identify lag spikes correlated with heavy write workloads
- Verify replicas catch up after maintenance windows
- Set a baseline for what "normal" lag looks like in your environment
Slot History
Track per-slot lag over time to identify which slots are falling behind.
Troubleshooting
Lag keeps increasing — the replica can't keep up with write volume. Check replica CPU/IO, network bandwidth, and max_wal_senders on the primary.
Slot is inactive with growing lag — no consumer is connected. Either reconnect the consumer or drop the slot to release retained WAL.
Lag spikes during maintenance — expected during VACUUM FULL, large CREATE INDEX, or bulk data loads. Lag should recover after the operation completes.