Revalidating

This page covers revalidation with Cache Components, enabled by setting cacheComponents: true in your next.config.ts file. If you're not using Cache Components, see the Caching and Revalidating (Previous Model) guide.
Revalidation is the process of updating cached data. It lets you keep serving fast, cached responses while ensuring content stays fresh. There are two strategies:
cacheLife controls how long cached data remains valid. Use it inside a use cache scope to set the cache lifetime.
cacheLife accepts a profile name or a custom configuration object:
For fine-grained control, pass an object:
A cache is considered "short-lived" when it uses the seconds profile, revalidate: 0, or expire under 5 minutes. Short-lived caches are automatically excluded from prerenders and become dynamic holes instead. See Prerendering behavior for details.
See the cacheLife API reference for all profiles and custom configuration options.
cacheTag lets you tag cached data so it can be invalidated on-demand. Use it inside a use cache scope:
Once tagged, invalidate the cache using revalidateTag or updateTag.
See the cacheTag API reference to learn more.
revalidateTag invalidates cache entries by tag using stale-while-revalidate semantics — stale content is served immediately while fresh content loads in the background. This is ideal for content where a slight delay in updates is acceptable, like blog posts or product catalogs.
You can reuse the same tag in multiple functions to revalidate them all at once. Call revalidateTag in a Server Action or Route Handler.
The second argument sets how long stale content can be served while fresh content generates in the background. Once it expires, subsequent requests block until fresh content is ready. Using 'max' gives the longest stale window.
See the revalidateTag API reference to learn more.
updateTag immediately expires cached data for read-your-own-writes scenarios — the user sees their change right away instead of stale content. Unlike revalidateTag, it can only be used in Server Actions.
See the updateTag API reference to learn more.
revalidatePath invalidates all cached data for a specific route path. Use it when you want to revalidate a route without knowing which tags are associated with it.
Prefer tag-based revalidation (revalidateTag/updateTag) over path-based when possible — it's more precise and avoids over-invalidating.
See the revalidatePath API reference to learn more.
Cache data that doesn't depend on runtime data and that you're OK serving from cache for a period of time. Use use cache with cacheLife to describe that behavior.
When content doesn't need time-based revalidation, for example data from a CMS, use cacheTag and a long cacheLife like max to keep it in the static shell. Configure the content source to trigger a webhook, or other notification, that calls revalidateTag when the content changes. This reduces unnecessary time-based revalidation for content that hasn't changed.
In serverless environments, in-memory cache entries may not persist across revalidations. See runtime caching considerations for details.
Learn more about the APIs mentioned on this page.
Last updated June 25, 2026
Subscribe to our newsletter
Stay updated on new releases and features, guides, and case studies.