# Replication oplog window monitoring (Oplog GB/Hour, Replication Headroom) > Source-anchored research for Replication oplog window monitoring (Oplog GB/Hour, Replication Headroom). Run status: COMPLETED. Parent: [Oplog sizing under storage auto-scaling](https://llms-explorer.com/tree/oplog-sizing-under-storage-auto-scaling/) · 4 facets · 16 facts · page: https://llms-explorer.com/tree/replication-oplog-window-monitoring-oplog-gb-hour-replication-headroom/ ## How it works - When lag exhausts retained oplog history, a secondary can no longer catch up from that history and may require a full resync. Monitor headroom and window together to detect the approach to that boundary. (high confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) - Atlas documentation states that replication headroom is collected at 85-second intervals regardless of project default granularity. Treat this as a sampled diagnostic signal when interpreting short workload bursts. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) ## Problems, failure modes and limitations - Ops Manager's troubleshooting documentation lists idle or infrequent writes as a possible cause of misleading reported lag and recommends checking whether lag persists; this is a documented diagnostic caveat, not evidence that every modern Atlas lag spike has that cause. (low confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/reference/alerts/replication-lag.md) ## Comparisons and alternatives - Replication headroom is the relevant sync source oplog window minus the secondary’s replication lag; it measures remaining history margin rather than free disk space. Atlas alert documentation names the sync source, while its metric overview describes the primary. (high confidence) — [source](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md) - An oplog window is workload-sensitive: rising oplog generation can shrink the window. Operational inference: compare window and lag trends after workload or capacity changes rather than treating a previous window measurement as a future guarantee. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) ## Facts and statements - The oplog window describes retained operation time. Percona measures the newest-to-oldest entry span in seconds; Atlas presents an estimated average in hours based on oplog churn. Normalize units before comparing either window with lag. (high confidence) — [source](https://docs.percona.com/percona-monitoring-and-management/3/reference/dashboards/dashboard-mongodb-replset-summary.html) - Oplog GB/Hour measures the primary's average hourly generation of oplog data; a high generation rate relative to configured oplog size corresponds to a short recovery window. (high confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) - Operational inference for storage auto-scaling: monitor storage separately from replication headroom. Atlas documents that insufficient oplog size can prevent disk auto-scaling; rising disk capacity therefore does not, by itself, establish adequate retained replication history. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md) - Grafana’s MongoDB integration documents separate critical alerts for excessive replication lag and low replication headroom. The public monitoring-mixins alert implementation also separates these two conditions. (medium confidence) (verified as of 2026-10-30) — [source](https://grafana.com/docs/learning-paths/mongodb-integration/install-dashboards-alerts/) - The inspected monitoring-mixins headroom rule averages oplog spans and member optimes by job and mongodb_cluster, and fires at a non-positive result for five minutes. Inference: these averages can conceal one badly lagging secondary, so assess member-level headroom as well as aggregate alerts. (medium confidence) (verified as of 2026-10-30) — [source](https://github.com/monitoring-mixins/website/blob/master/assets/mongodb/alerts.yaml) - Atlas describes Oplog GB/Hour in terms of uncompressed oplog data. Treating this number as compressed physical disk growth would conflate different measurements. (low confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) - Atlas defines Replication Headroom as the primary's replication oplog window minus the secondary's replication lag. (low confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) - Monitor headroom alongside replication lag to assess whether a secondary risks falling outside retained oplog history; lag alone does not describe the remaining history margin. (high confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) - Percona's ReplSet Summary defines its recovery window as newest-entry timestamp minus oldest-entry timestamp. Its Oplog Details dashboard separately labels Oplog Range and Now to End, with the latter measured from the current time to the oldest entry; these panel definitions should not be assumed interchangeable with Atlas's churn-based estimate. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics.md) - Percona's Oplog Details buffer-capacity panel measures fetched but unapplied entries, with Used and Max in bytes. That buffer is distinct from the time span of retained oplog history. (low confidence) — [source](https://docs.percona.com/percona-monitoring-and-management/3/reference/dashboards/dashboard-mongodb-oplog-details.html) - Grafana Cloud's documented MongoDB integration includes a ReplicaSet dashboard and a MongodbReplicationHeadroom condition for low headroom. (low confidence) (verified as of 2026-10-30) — [source](https://grafana.com/docs/learning-paths/mongodb-integration/install-dashboards-alerts/)