must-revalidate

Caching

Once content becomes stale, the cache must revalidate with the origin before serving it. The cache cannot serve stale content even if the origin is unreachable. This ensures users never see outdated content, but can cause errors if the origin is down.

Updated Apr 3, 2026

Full Explanation

must-revalidate is a strict directive that tells caches: once the content is stale, you are not allowed to serve it without first checking with the origin. Without this directive, caches are technically permitted to serve stale content in certain situations (like when the origin is unreachable). This directive closes that loophole.

The typical pattern is pairing it with max-age. During the freshness window, the cache serves content normally. After that, every request triggers a revalidation. If the origin is down and cannot be reached, the cache returns a 504 Gateway Timeout rather than serving the stale copy. That is the tradeoff: you get guaranteed freshness, but you lose resilience during outages.

Cache-Control: public, max-age=300, must-revalidate

This is the right choice for content where serving outdated data could cause real problems. Think financial data, inventory counts, user account details, or anything where staleness leads to bad decisions. For content where a stale page is better than an error page, look at stale-if-error or stale-while-revalidate instead.

Examples

For financial data or sensitive content where staleness is unacceptable, combine a short TTL with must-revalidate:

Cache-Control: public, max-age=60, must-revalidate

This caches the response for 60 seconds. After that, the cache must check with the origin before serving. If origin is down, the user gets a 504 instead of potentially stale financial figures.

In nginx, you would set this for your API endpoints:

location /api/account/balance {
    add_header Cache-Control "private, max-age=10, must-revalidate";
}

Frequently Asked Questions

Once content becomes stale, the cache must revalidate with the origin before serving it. The cache cannot serve stale content even if the origin is unreachable. This ensures users never see outdated content, but can cause errors if the origin is down.

For financial data or sensitive content where staleness is unacceptable, combine a short TTL with must-revalidate:

Cache-Control: public, max-age=60, must-revalidate

This caches the response for 60 seconds. After that, the cache must check with the origin before serving. If origin is down, the user gets a 504 instead of potentially stale financial figures.

In nginx, you would set this for your API endpoints:

location /api/account/balance {
    add_header Cache-Control "private, max-age=10, must-revalidate";
}

Related CDN concepts include:

  • proxy-revalidate — Like must-revalidate, but only applies to shared caches (CDNs). Browser caches can still serve stale …