Does disabling container-level TTL stop background cleanup of expired items?

Question

An Azure Cosmos DB SQL (Core) API container previously had time-to-live enabled at the container level. Several items already contain expiration timestamp values, and some timestamps have passed while TTL was active.
After disabling container-level TTL, it is unclear whether the asynchronous background cleanup continues to remove items whose expiration timestamps have already passed, or whether disabling the container setting cancels their pending expiration and leaves them readable indefinitely.
Does disabling container-level TTL stop background cleanup of items that already have expiration timestamps, and does the read consistency level affect whether those expired items are still returned before cleanup completes?

Tasadduq Burney · Answer

No. Disabling the container‑level TTL does not stop the background cleanup of items that already have expiration timestamps; it only stops the service from evaluating the _ttl field for any item, so items whose timestamps have already passed stay readable until they are manually removed or the container‑level TTL is re‑enabled.

Likely explanation: The background TTL cleanup runs asynchronously on a schedule of hours and is best‑effort. When the container default TTL is set to –1, the service stops checking the _ttl value for all items, regardless of whether the expiration time is in the past. Consequently, the cleanup job no longer acts on any item that relies on the container default or on an explicit per‑item _ttl.

Confirmed facts (as documented by Azure Cosmos DB documentation):

The container property defaultTtl set to –1 disables TTL evaluation for the container.
Items that have an explicit _ttl property are still stored but are ignored by the background cleanup when the container default is –1.
Background deletion is not immediate; it may take hours to locate and delete expired items after a TTL change.
Read consistency level (strong, bounded, eventual) determines when a delete write becomes visible, not whether an expired item is returned before the physical delete occurs.

Steps to verify and act:

Confirm the container’s defaultTtl is –1 after the change (via SDK or portal).
Query a known expired item by its ID (point read) and verify it is still readable.
If immediate removal is required, delete the item manually or re‑enable container TTL (set defaultTtl to a positive value) and allow the background job to run.
Monitor the change feed or run periodic point reads to see when deletions occur after re‑enabling TTL.

To give a precise recommendation, please indicate whether the expired items were using the container’s default TTL or an explicit per‑item _ttl value, as that determines whether manual deletion or re‑enabling TTL is required.

Does disabling container-level TTL stop background cleanup of expired items?

1 answer

Your perspective belongs here.

0 question comments