Replica Lag (seconds), MongoDB

​

At a glance

Replica Lag (seconds) is how far behind the primary the slowest secondary is, measured as the gap between the primary’s most recent oplog entry and the secondary’s last-applied oplog entry. It answers two operational questions at once: “if the primary dies right now, how much data could I lose?” and “are my secondary reads stale?” Healthy lag is sub-second to a couple of seconds. The card alerts at 10s, because beyond that a failover risks data loss, secondary reads serve noticeably stale data, and a member may be on its way to falling off the oplog entirely.

​

Calculation

1. Idle-write artefact. Lag is computed from oplog timestamps. On a set with little write traffic, a secondary can show a few seconds of apparent lag simply because the primary has not written a new oplog entry recently, so the secondary’s last-applied entry is “old” without the secondary actually being behind. The engine treats this the way MongoDB does, by comparing against the primary’s latest optime; on genuinely idle sets a small, stable reading is expected and is not a fault.
2. Arbiters and delayed members excluded. Arbiters hold no data and report no meaningful optime, so they are excluded. Intentionally delayed members (configured with secondaryDelaySecs for point-in-time recovery) are excluded from the alerting maximum where the connector knows their configured delay, so a deliberately delayed hidden member does not constantly trip the 10s alert.

​

Worked example

1. Failover risk. If node-a fails in this state, an election would prefer node-b (only 2s behind), but if node-b were also unavailable, promoting node-c would lose up to 47 seconds of acknowledged-on-primary writes that node-c never applied. That is potential order data loss.
2. Stale secondary reads. The reporting dashboards reading from node-c are showing data nearly a minute old. For inventory counts during a busy period, that staleness can cause overselling decisions.

Reading the lag trend:
  lag flat and small (0-3s)        -> healthy, normal replication
  lag flat but elevated on idle set -> oplog-timestamp artefact, usually benign
  lag climbing steadily            -> secondary cannot keep up; will fall off the oplog -> resync
  lag spikes then recovers          -> a transient (a long write, an index build, a network blip)

1. Lag is your real-world RPO. The recovery-point objective is not a config setting; it is whatever this card reads at the moment the primary fails. A 47s lag means up to 47s of potential data loss on an unlucky failover.
2. The trend matters more than the absolute value. A flat 12s is far less alarming than a 4s reading that doubles every minute. Climbing lag means the secondary is losing the race against the write rate and heading for a resync.
3. Stale reads are a silent correctness bug. If you read from secondaries, lag directly degrades data freshness. A dashboard or an inventory check on a lagged secondary is quietly serving old numbers; tie read-staleness expectations to this card.

​

Sibling cards

​

Reconciling against the source

Run rs.printSecondaryReplicationInfo() in mongosh for the per-secondary lag figures the card is built from, or rs.status() to read each member’s optimeDate and compute the gap against the primary yourself. Check db.printReplicationInfo() on the primary to see the oplog window (first-to-last entry time span); the lag must stay well inside this window or the secondary will fall off and need a full resync. On MongoDB Atlas, the Metrics tab exposes a “Replication Lag” chart per secondary node; pick the most-lagged node to match the card’s maximum-across-secondaries reading. rs.status().members[].stateStr confirms whether a lagged member has dropped into RECOVERING.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre