Review conflicting directives before relying on Cloudflare stale-while-revalidate

A configured stale window can be defeated by directives that require validation before use.

Source facts

Cloudflare documents stale-while-revalidate as allowing expired content to be served while refreshing in the background. With Origin Cache Control enabled, must-revalidate, proxy-revalidate, s-maxage, and no-cache prevent stale serving. The source describes UPDATING during asynchronous refresh and recommends separate edge TTL configuration when different edge and browser lifetimes are needed without s-maxage’s revalidation semantics.

Source: Cloudflare — Revalidation.

Applicability

This concerns Cloudflare’s documented revalidation behavior.

DSE recommendation

DSE recommends reviewing the complete response-header set rather than adding a stale directive in isolation. Classify which public content can tolerate the proposed stale interval and which responses must consult the origin. Keep edge TTL, browser TTL, and stale allowance as separate design choices. Record cache-rule overrides alongside origin directives so a later performance change does not silently change the application’s freshness contract. Have the content owner approve a concrete maximum tolerated age for the pilot resource. Preserve the full directive set with each result and test the conflict deliberately, so a future header cleanup cannot silently reverse the accepted decision about serving stale content during refresh.

Verification

Use a controlled public test resource with a visible revision marker and short test lifetimes. Observe requests across expiry and correlate statuses with origin refresh timing. Repeat with a conflicting directive deliberately present in the test environment. Confirm the intended behavior before applying the policy to production content, without presenting the test as an availability guarantee.

Official reference

Cloudflare — Revalidation. Reviewed October 20, 2026.