# Oplog minimum retention window and storage auto-scaling > Source-anchored research for Oplog minimum retention window and storage auto-scaling. Run status: COMPLETED. Parent: [Atlas storage auto-scaling and disk reclaim via compact](https://llms-explorer.com/tree/atlas-storage-auto-scaling-and-disk-reclaim-via-compact/) · 4 facets · 15 facts · page: https://llms-explorer.com/tree/oplog-minimum-retention-window-and-storage-auto-scaling/ ## How it works - Percona ClusterSync guidance says destination capacity must include both the dataset and the oplog generated by applied changes; it suggests reducing minimum retention when extended history is unnecessary to reduce destination disk usage. (low confidence) (verified as of 2026-10-31) — [source](https://docs.percona.com/percona-clustersync-for-mongodb/oplog-sizing.html) - A September 2023 Terraform provider issue reported HTTP 400 OPLOG_MIN_RETENTION_HOURS_NO_DISK_AUTO_SCALING when switching from disk auto-scaling to NVMe while unsetting retention. The reporter found null left the old value unchanged and a simultaneous change to zero also failed. This is historical evidence, not verification of current provider behavior. (low confidence) (verified as of 2026-10-31) — [source](https://github.com/mongodb/terraform-provider-mongodbatlas/issues/1481) ## Problems, failure modes and limitations - Check rs.printReplicationInfo() for oplog size and time range. Percona also recommends comparing db.getReplicationInfo().timeDiff with migration lagTime and enlarging the window before lag reaches that limit; timeDiff reports available history, not the configured minimum-retention parameter. (high confidence) — [source](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md) - Atlas explicitly warns against reducing oplog size as a way to free disk for other collections: the saved space remains reusable only by local.oplog.rs. Removing retained history can also remove entries that Atlas cannot restore. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md) ## Comparisons and alternatives - The observed oplog window is the time between the oldest and newest oplog timestamps. A configured minimum retention period is a separate setting; monitor the observed window rather than assuming it always equals the setting. (high confidence) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - Atlas Core enables storage auto-scaling by default and uses minimum oplog retention to manage entries when it is enabled. Atlas documents a default minimum window of 24 hours, unlike the server default with no minimum. (high confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) ## Facts and statements - MongoDB removes an oplog entry under minimum-retention rules only after the configured oplog size is reached and the entry is older than the retention period. The server default has no minimum retention period. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md) - Atlas Core delays an auto-scaling event until the observed oplog window covers the estimated scaling time; setting an adequate minimum window helps prevent this delay. (high confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - Atlas storage documentation describes the required retention window for successful storage auto-scaling as up to 60 seconds multiplied by configured disk GB. Treat this as sizing guidance tied to configured capacity, and confirm the required window for the actual scaling operation. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - Atlas explicitly warns that high-volume bulk writes, including migrations, can prevent the cluster from maintaining its configured minimum oplog window. A configured 24-hour minimum therefore should not be treated as an unconditional observed-history guarantee. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - On Atlas Core, minimum-window configuration requires storage auto-scaling; a fixed oplog-size setting requires opting out. Atlas does not permit replSetResizeOplog for resizing, so self-managed command examples must be translated to Atlas settings. (high confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/customize-storage.md) - Migration and CDC consumers need their required operations to remain available until consumed. Before shortening retention to save storage, compare consumer lag and planned interruptions against the observed oplog window; expiry can force a fresh data load or failed sync. (high confidence) — [source](https://docs.percona.com/percona-clustersync-for-mongodb/oplog-sizing.html) - A February 2023 Atlas user reported that the observed oplog window shrank during a write surge despite a compute upgrade to M30. This illustrates an operational report to investigate; it does not establish a current Atlas defect or retention guarantee. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/community/forums/t/oplog-window-best-practice-value/215225) - The oplog-window scaling prerequisite is scoped to Atlas Core. Atlas documents that minimum oplog retention does not affect auto-scaling on Atlas Infinite. (high confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling.md) - Hevo recommends capacity for 72 hours of oplog history to accommodate sudden event influxes. This is a connector recommendation, not an Atlas default or a universal minimum. (low confidence) (verified as of 2026-10-31) — [source](https://docs.hevodata.com/sources/dbfs/databases/mongodb/)