# Time series collection expireAfterSeconds > Source-anchored research for Time series collection expireAfterSeconds. Run status: COMPLETED. Parent: [Data Lifecycle Cost Model (TTL vs Online Archive vs Data Federation)](https://llms-explorer.com/tree/data-lifecycle-cost-model-ttl-vs-online-archive-vs-data-federation/) · 5 facets · 14 facts · page: https://llms-explorer.com/tree/time-series-collection-expireafterseconds/ ## How it works - Mongoose issue 11229 recorded a historical timeseries expireAfterSeconds schema-option and TypeScript problem and closed through fix 11489 in the 6.2.7 milestone. The Mongoose guide includes the collection option and requires explicit Model.createCollection() before inserting when autoCreate is false; inserting first can create an ordinary collection. (medium confidence) (verified as of 2026-10-30) — [source](https://github.com/Automattic/mongoose/issues/11229) ## How-to and procedures - Enable or change time-series expiration with db.runCommand({collMod: "collection", expireAfterSeconds: seconds}); set expireAfterSeconds to "off" to disable it. This is the collection-level collMod option, distinct from index.expireAfterSeconds. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-automatic-removal.md) ## Problems, failure modes and limitations - MongoDB removes a time-series bucket once all its measurements have expired. The bucket expiration threshold is its upper timestamp limit plus expireAfterSeconds. Therefore, configured measurement retention does not imply immediate physical removal of each measurement. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-automatic-removal.md) - The TTL manual documents partial TTL indexes for time-series collections starting in MongoDB 7.0: the key uses timeField and the partial filter uses metaField. With collection-level expiration enabled, such an index can shorten matching data retention but cannot extend it beyond the collection threshold. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md) - Percona documents that during a PBM logical restore, including point-in-time recovery, collection-level expireAfterSeconds can delete time-series buckets needed by oplog replay and cause a missing control-field error. Its procedure disables ttlMonitorEnabled on every target data-bearing mongod during restore and restores the original values afterward; disabling the monitor pauses all TTL-managed expiration. (low confidence) (verified as of 2026-10-05) — [source](https://docs.percona.com/percona-backup-mongodb/latest/usage/restore.html) ## Comparisons and alternatives - The collection-level expireAfterSeconds option sets measurement expiration relative to the configured timeField value, rather than insertion time. Place it alongside timeseries in the createCollection options; 86400 means a one-day expiration threshold. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-automatic-removal.md) ## Facts and statements - The expired-bucket background task runs every 60 seconds, but workload can delay actual removal beyond that interval. A capacity model must allow for bucket-level retention and deletion backlog; 60 seconds is not a deletion-latency guarantee. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-automatic-removal.md) - For the documented granularity presets, a bucket can cover one hour for seconds, 24 hours for minutes, or 30 days for hours. These spans explain why older measurements can remain after their individual expiration threshold; this table does not describe custom bucket settings. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-automatic-removal.md) - Inspect listCollections output at options.expireAfterSeconds to verify that a time-series collection actually has the intended expiration policy. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-automatic-removal.md) - Percona's logical-restore guidance warns that time-series expireAfterSeconds can let the TTL monitor delete buckets needed by oplog replay, causing Location6781400 ('Time series bucket document is missing control field'). It recommends disabling ttlMonitorEnabled on every target data-bearing mongod during restore and restoring each original setting afterward; disabling the monitor suspends all TTL-managed expiration. (low confidence) (verified as of 2026-10-20) — [source](https://docs.percona.com/percona-backup-mongodb/latest/usage/restore.html) - The Mongoose master guide retrieved on 2026-10-30 shows expireAfterSeconds as a top-level schema option alongside timeseries. With autoCreate:false, it instructs applications to explicitly create the collection before inserting; an earlier insert can implicitly create an ordinary collection. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/Automattic/mongoose/blob/master/docs/guide.md) - Mongoose issue 11229 recorded a historical report with Mongoose 6.1.6 in which expireAfterSeconds was absent from SchemaOptions typings and the collection metadata. The issue is closed and assigned milestone 6.2.7; this historical report does not establish a defect in current Mongoose. (low confidence) — [source](https://github.com/Automattic/mongoose/issues/11229) - Historical MongoDB issues SERVER-76560 and SERVER-79864 scope TTL correctness problems to certain configurations and extended-range dates. Their listed fix versions include 6.0.13 and 7.0.5; SERVER-79864 describes disabling TTL for collections with extended-range dates as its workaround. These records do not establish the present behavior of every later release. (medium confidence) — [source](https://jira.mongodb.org/browse/SERVER-76560) - MongoDB SERVER-99527 documents premature TTL deletion after non-metaField deletes followed by adjacent-time inserts under specified index conditions. Its impact statement identifies affected versions 7.0.0–7.0.15 and 8.0.0–8.0.3, with fixes listed for 7.0.16 and 8.0.4. This is a historical defect with explicit prerequisites, not the intended retention behavior. (low confidence) (verified as of 2025-08-07) — [source](https://jira.mongodb.org/browse/SERVER-99527)