Atlas: diagnose replication lag on secondaries

TL;DR: Secondaries fall behind the primary and stale reads or failover risk follow. Find whether it is load, sizing, or a single slow operation. Check the oplog window: if the window is short, a lagging secondary risks falling off entirely. Confirm If lag correlates with primary write spikes or an index build, it is load-induced.

The error

the Replication Lag metric climbs; secondary reads return stale data; failover would lose recent writes.

The fix

1. Atlas Metrics: replication lag per node, plus CPU and disk on the lagging secondary. A saturated secondary cannot apply the oplog fast enough.
2. Look for long-running writes on the primary: huge multi-updates and index builds generate oplog volume that buries secondaries.
3. Check the oplog window: if the window is short, a lagging secondary risks falling off entirely.
4. Move heavy batch work off peak; split huge multi-updates into smaller batches.
5. Build big indexes with the rolling build option on dedicated clusters so secondaries are not buried.
6. If a secondary is persistently behind on normal load, the tier is undersized: scale up.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Atlas.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Atlas behavior.

Replication lag and oplog metrics per https://www.mongodb.com/docs/atlas/monitor-cluster-metrics/, verified 2026-09-26.