Should the revalidate route segment config option update the Cache-Control header?

[pauledwards241]

On one of our pages, we've added a dynamic route segment config and set it to:

export const dynamic = 'force-static';

This changes the page Cache-Control header to:

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

I then assumed adding a revalidate route segment config e.g.

export const revalidate = 600; // 10 minutes

Would update the Cache-Control header to:

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

But that's not the case. Based on this 2023 StackOverflow discussion, it should. However, it is 1.5 years old.

Is that expected? Does Next.js work out when to revalidate from other response headers instead?

We are hosting on Vercel if that makes a difference.

[SametDulger]

Hi @pauledwards241,

Great question! Here’s how Next.js handles the revalidate route segment config and Cache-Control headers currently:

Setting export const revalidate = 600 does not directly update the Cache-Control header to max-age=600.

Instead, Next.js manages revalidation internally and sets cache headers based on its own logic and hosting platform (like Vercel).

For dynamic = 'force-static', Next.js adds Cache-Control: public, max-age=0, must-revalidate to ensure the content is fresh but still cached by browsers/CDNs.

The actual revalidation timing for ISR is controlled server-side, often by a separate header or platform config, not purely by the Cache-Control max-age.

On Vercel, ISR revalidation is handled by their edge network, so you might not see max-age=600 reflected in the response headers, but revalidation happens as configured.

So yes, this behavior is expected with current Next.js versions and hosting on Vercel.

If you want full control over Cache-Control headers, you might consider setting them manually in route handlers or middleware.

Let me know if you want examples on how to customize caching headers or more info on ISR internals!

[pauledwards241]

Thanks for your detailed reply @SametDulger. We are currently adding the Cache-Control header through next.config.js, but I just wanted to check if this was necessary and we weren't missing something obvious with the route config.