iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Time-based Incremental Static Regeneration (ISR) in Next.js does not rebuild a page the moment its revalidation interval expires. The documented flow waits for a request after the interval, so a page that nobody requests can stay at its old version. That explains part of the problem, but not all of it. A page can also stay stale because an on-demand invalidation never reached the right target, because a regeneration failed, or because a cache layer outside Next.js is holding the old copy.
How time-based ISR regenerates a page
The Next.js App Router and Pages Router ISR guides describe the same basic sequence for time-based revalidation, though the configuration syntax differs by router.
- The page is generated and cached with a revalidation interval. The official guides use examples such as 60 seconds and one hour (Next.js documentation examples, 2026). These are illustrative values, not measured refresh rates or recommended settings for any site.
- The interval expires, but regeneration does not start by itself. The cached entry becomes eligible for revalidation, and the documented time-based flow waits for a later request before it regenerates the page. The docs give no basis to expect a refresh from the timer alone. See the App Router ISR guide and the Pages Router ISR guide.
- The next visitor receives the cached version. That copy may be stale, because Next.js regenerates the page in the background while the request is answered.
- Later visitors receive the new version once regeneration succeeds. The official documentation puts it this way: “Once the new version is successfully generated, it replaces the cached version, and subsequent visitors will receive the updated content.”
The practical consequence is that the first request after expiry is the one that triggers a refresh. A route that gets no traffic after its interval gets no refresh, and the old copy stays in place until someone visits it.
Recommended Free Tools
Where “nobody visited it” is only part of the story
The explanation above is accurate for time-based revalidation. It does not cover every reason an ISR page looks old, and it does not account for on-demand invalidation, which Next.js also supports.
#1 Best Overall
On-demand invalidation is an explicit trigger, and it can miss
If a page must change when content changes, waiting for the next visit is the wrong model. On-demand revalidation lets your application invalidate a path or tag when the content changes. The failure mode is that the invalidation call targets the wrong path or tag, or never runs because a webhook or application action failed. In that case the page keeps its cached copy regardless of traffic, until the interval expires (if it has one) or a correct invalidation runs.
Regeneration can fail without replacing the cache
A successful regeneration replaces the cached version. A failed attempt keeps the last successful data available, so the page continues to show the previous version. A regeneration failure therefore looks like a stale page, even when the route is receiving visits. Check the server logs for the failed attempt rather than assuming the cache updated.
Rank #2
Cache layers outside Next.js can hold the old copy
Self-hosted deployments, multiple application instances, and CDNs can add cache behavior of their own. The Next.js self-hosting guide in the framework’s source repository covers how the framework’s caching fits into a self-hosted setup. Without knowing your architecture, the framework cannot tell you which layer is holding the copy, so you need to check each one.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsMaking a change appear without waiting for a visit
Use the on-demand method that matches your router. The two routers expose different APIs, so do not treat them as interchangeable.
| Router | On-demand method | Invalidation target | When the new version is generated |
|---|---|---|---|
| App Router | revalidatePath |
A path | On the next request, according to the App Router ISR guide |
| App Router | revalidateTag |
A cache tag | On the next request, per the Next.js 15 caching guide for the same mechanism |
| Pages Router | res.revalidate |
Not stated in the cited guide | Not stated in the cited guide |
The table shows that invalidation and regeneration are separate steps. Invalidating a path does not mean the new HTML already exists; the App Router guide says regeneration happens on the next request. The Next.js 15 caching guide is versioned and should be used to explain the concept, not to confirm behavior in your installed version.
Checking a page that still looks old
- Identify the router and Next.js version. Confirm whether the route lives under the App Router or the Pages Router, and which version is installed. The guides are separate and version-dependent.
- Determine the route’s revalidation mode. Decide whether it uses time-based revalidation, on-demand invalidation only, or both. A page with neither will not refresh on a schedule.
- Verify the invalidation target. Log the path or tag your application passes to
revalidatePathorrevalidateTag, and confirm it matches the path or tag the page actually reads from. - Confirm regeneration succeeded. Check server logs for the regeneration attempt after the request that should have triggered it. A failed attempt keeps the last good version.
- Check cache hits and misses. The current App Router ISR guide notes that logging can show cache hits and misses, which tells you whether the request reached the origin or was served from a cache.
- Test Pages Router routes in production mode. The Pages Router guide recommends verifying with
next buildfollowed bynext start, rather than relying on the development server. - Inspect every layer for self-hosted or CDN-backed sites. Review the cache layers and any shared or persistent cache configuration that applies to your deployment. Hosted platforms such as Vercel document their own ISR setup in the Vercel ISR quickstart, which describes that platform’s behavior and is not a recommendation of it.
What the evidence does and does not show
The official Next.js guides explain the mechanisms, but they do not publish how often ISR pages remain stale in production. No independent study measuring that rate was found in the sources reviewed for this article, so no prevalence figure should be attached to the claim that unvisited pages stay old.
Community discussion sometimes puts the concern in stronger terms. One public r/nextjs thread asks: “Doesn’t this mean people might potentially be getting pages that are months or years out of date if no-one has visited that url for a while?” That is a developer’s question, not documentation, and it describes a possibility the time-based flow allows rather than a measured outcome. The thread is useful for seeing how developers frame the concern, not for establishing how common it is.
Some ISR behavior is also deployment-specific. Rather than assuming the framework’s documented behavior applies unchanged to your hosting, confirm it against the Next.js version you run and the cache layers between your users and your origin.
Readers who want the full mechanism should start with the App Router ISR guide, then compare against the Pages Router ISR guide if the project uses that router.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
