Do not use Cloudflare TTL as a promise that an object remains in cache

Freshness policy and eviction-driven retention answer different operational questions.

Source facts

Cloudflare distinguishes freshness, the period an object can be used without checking its source, from retention, how long it remains stored before eviction. The source describes retention as influenced by popularity and cache capacity and not directly configurable. A fresh object can therefore be absent when requested again, while an expired retained object may need revalidation.

Source: Cloudflare — Retention vs Freshness (TTL).

Applicability

This concerns Cloudflare CDN cache semantics.

DSE recommendation

DSE recommends writing performance and resilience expectations without assuming every object survives for its full TTL. Keep the origin capable of serving a cache miss and size it for a credible miss pattern. Use versioned assets and a deliberate invalidation process for changes. Separate the desired freshness interval from any requirement to preserve data, which needs an appropriate storage and recovery design outside an ordinary CDN cache. Review the origin-capacity plan using a cold-cache scenario, even when the chosen freshness interval is long. Ask the service owner to state where recoverable master content lives and how it is restored. Keep that answer outside the CDN’s freshness and hit-rate objectives.

Verification

Observe representative assets over time with cache status and origin-request evidence. Distinguish an evicted miss from a freshness revalidation instead of treating both as a TTL failure. Test origin behavior under an approved cold-cache workload and record capacity findings without asserting a guaranteed retention period from a configured expiry value.

Official reference

Cloudflare — Retention vs Freshness (TTL). Reviewed October 20, 2026.