Incremental Static Regeneration & Time-Based Revalidation

The plain-language idea

Incremental Static Regeneration (ISR) lets a statically rendered page update itself after deployment, without a full rebuild. The classic, route-segment-level way to enable it is a single export:

export const revalidate = 3600; // seconds

This works whether or not Cache Components (cacheComponents: true) is enabled — it's the older, simpler caching model, and it's still fully present and supported in Next.js 16 for routes that aren't using "use cache".

The behavior is stale-while-revalidate: the first request after the revalidate window passes still gets the existing cached page immediately — the visitor never waits — while Next.js regenerates a fresh version in the background. Once that regeneration finishes, the new version replaces the cached one and every subsequent visitor gets the updated content. No visitor ever blocks on a rebuild; they either get the current cache or the previous one, never a loading spinner for the regeneration itself.

See it in a real thing: a blog list that updates every hour

// app/blog/page.tsx
interface Post {
  id: string;
  title: string;
}

export const revalidate = 3600; // invalidate at most once per hour

export default async function BlogPage() {
  const data = await fetch("https://api.example.com/blog");
  const posts: Post[] = await data.json();
  return (
    <main>
      <h1>Blog Posts</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </main>
  );
}

For the first hour after this page is built or last regenerated, every request gets the same cached HTML, instantly, straight from cache. The first request after that hour passes still gets that same (now stale) cached HTML immediately — but it also triggers a background regeneration. Once that finishes, the cache is replaced, and the next visitor after that gets the fresh version. If an error happens during that background regeneration, Next.js keeps serving the last successfully generated version and just retries on the next request, rather than showing visitors a broken page.

What people usually miss

Watch out

• A stale request is never a slow request. The visitor who lands right after the revalidation window expires gets the old cached page immediately — they are never the one waiting for the regenerated version; regeneration happens for the next visitor's benefit, invisibly, in the background.
• revalidate must be a statically analyzable literal. export const revalidate = 600 is valid; export const revalidate = 60 * 10 is not — Next.js needs to read the value without executing arbitrary code.
• In development, pages are always rendered on-demand, never cached — revalidate has no visible effect until a real production build (next build && next start), which is exactly why testing ISR behavior in dev mode is misleading.
• If multiple fetch() calls in the same route have different revalidate values, the lowest one wins for the whole route — a single fast-changing fetch forces more frequent regeneration for everything else on that page too.
• On-demand revalidation (revalidateTag/revalidatePath) and time-based revalidate aren't mutually exclusive. A page can have a one-hour time-based fallback and also get invalidated immediately after a specific mutation — whichever happens first wins.

Why this matters in interviews

"Why didn't the page update immediately after I changed revalidate and made a request?" tests whether a candidate actually understands stale-while-revalidate semantics — the correct answer is that the very next request after the window closes still gets stale content and merely triggers the regeneration, it doesn't wait for it.