# Replication Lag Monitoring > Source-anchored research for Replication Lag Monitoring. Run status: COMPLETED. Parent: [MongoDB Monitoring and Observability](https://llms-explorer.com/tree/mongodb-monitoring-and-observability/) · 6 facets · 15 facts · page: https://llms-explorer.com/tree/replication-lag-monitoring/ ## Definitions - Replication lag is the time a secondary's replicated progress trails the primary's latest operation. `rs.printSecondaryReplicationInfo()` reports seconds behind and the `syncedTo` time for each secondary; monitoring systems can also calculate the offset from primary and secondary operation timestamps. (high confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md) ## How it works - Lag alone does not identify its cause. Correlate it with member state, network latency such as `pingMs`, secondary disk and cache pressure, and write workload to distinguish network, resource, and workload problems. (high confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md) - Track replication lag together with oplog headroom. Cloud Manager defines headroom as the sync source's oplog window minus secondary lag and states that a secondary can enter RECOVERING when headroom reaches zero; PMM says lag approaching the oplog recovery window may require a full resync. (high confidence) — [source](https://www.mongodb.com/docs/cloud-manager/reference/alerts.md) - The OpenTelemetry Collector MongoDB receiver emits replica-set lag and headroom only when scraping the primary, and those metrics require the clusterMonitor role; its documentation says to leave them disabled where a managed service restricts that role. (low confidence) (verified as of 2026-10-22) — [source](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/mongodbreceiver/README.md) - For an intentionally delayed member, do not assume the reported lag always equals secondaryDelaySecs: MongoDB documents a case where it reports 0 seconds behind when the primary's inactivity period exceeds that configured delay. (low confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md) ## How-to and procedures - Check measurement semantics before comparing lag values across tools. Cloud Manager describes its lag as approximate write-application delay and says the value is only accurate above roughly 1–2 seconds; the OpenTelemetry receiver tags its lag metric as applied or durable progress. (medium confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/cloud-manager/reference/alerts.md) ## Problems, failure modes and limitations - Treat thresholds as tool-specific starting points: MongoDB warns that an idle replica set can show elapsed time since the last write as lag and recommends alerting only after lag persists for more than two minutes to reduce false positives, while PMM 3 shows a 10-second red threshold line and describes sustained lag above it as a sign that the secondary cannot keep up. These examples do not establish a universal threshold. (medium confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/cloud-manager/reference/alerts/replication-lag.md) - When lag rises, correlate the affected member's measurements with network latency, disk throughput, and cache pressure. MongoDB documents network problems, secondary resource exhaustion, and slow secondary disks as causes; PMM also identifies network latency, secondary I/O bottlenecks, excessive primary write load, and high iowait with replication lag. (high confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md) ## Comparisons and alternatives - On an idle or low-write replica set, a wall-clock lag value can reflect time since the last write instead of an ongoing backlog. Use an alert persistence interval and consider primary write activity before paging; a single sample can create a false positive. (medium confidence) — [source](https://www.mongodb.com/docs/cloud-manager/reference/alerts/replication-lag.md) ## Facts and statements - Sustained replication lag can make a member less able to become primary quickly and can increase the chance of inconsistent distributed reads. If a secondary falls behind beyond the oplog history it needs, it may require an initial sync. (high confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md) - Monitor lag for each secondary as a trend, and pair it with oplog window or headroom. Headroom measures the time margin before a member falls off the end of the oplog; if lag approaches the available history, the secondary may fall out of sync and require a full resync. (high confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md) - The OpenTelemetry MongoDB receiver documentation defines `mongodb.replica_set.lag` and `mongodb.replica_set.headroom` as gauges in seconds, labels the replica name, and distinguishes lag measured against applied or durable progress. (low confidence) (verified as of 2026-10-22) — [source](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/mongodbreceiver/documentation.md) - A Percona Community Forum user reported PMM lag metric series of 0, 3600, and 7200 seconds for replica set members configured with secondary delays of 0, 3600, and 7200 seconds. Compare lag readings with intentional member delays before treating them as unexpected backlog. (low confidence) — [source](https://forums.percona.com/t/pmm-2-28-0-mongodb-replication-lag-with-delayed-nodes/15851) - A 2022 Bitnami chart issue reported that the metrics endpoint exposed `mongodb_up_1` without other metrics while the chart included replica lag alert rules. Check that the exporter actually emits the replica metrics before relying on configured alerts. (low confidence) — [source](https://github.com/bitnami/charts/issues/11404) - MongoDB's rs.printSecondaryReplicationInfo() reports lag per secondary with its syncedTo timestamp and seconds-behind value; the OpenTelemetry Collector MongoDB receiver defines mongodb.replica_set.lag as a seconds gauge with a replica-name attribute and an applied or durable progress-type attribute. (high confidence) (verified as of 2026-10-22) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md)