Replication Lag
How far behind a replica is, measured in time or in log position — the quantity that determines how stale a replica read can be.
The metric that turns "eventually consistent" into a number you can reason about, and the one most often unmonitored until it causes an incident.
Measure it in both units. Log position (bytes or LSN behind the primary) shows how much work the replica has to do. Time — the age of the newest applied transaction — is what maps to user experience and is what an SLO should be written against.
Lag is not caused by one thing, and the causes need different fixes. Write burst on the primary overwhelming the replica's single-threaded apply. A long-running query on the replica blocking apply to avoid removing rows it is reading. Network saturation between primary and replica. A schema change or bulk operation generating enormous log volume. The replica being under-resourced relative to the primary, which is common because replicas are often provisioned smaller.
Two practical requirements. Alert on it, with a threshold derived from what the application can tolerate. And make it visible to the routing layer, so a replica that exceeds the threshold is removed from the read pool rather than silently serving stale data — the failure mode where correctness quietly degrades while every dashboard stays green.