Next.js ISR & Build Logs: diagnosing deployment failures and resolving revalidation strategy

The short answer

A clean build log tells you nothing about ISR behavior after deployment. Your build only proves the page was generated once at build time; every later regeneration happens at runtime, on the first request after the revalidate window expires. ISR is time-triggered, not data-triggered — Next.js has no way to know your CMS changed. It simply waits for the interval to elapse, then regenerates on the next incoming request and serves whatever getStaticProps fetches at that moment.

Why you're likely seeing stale content

Three causes cover most cases like this:

1. The revalidate window hasn't elapsed. If revalidate is 3600 and the CMS updated 10 minutes ago, the stale page is correct behavior.
2. Stale-while-revalidate semantics. The first request after expiry still receives the old page while regeneration runs in the background; the fresh version appears on the subsequent request. One check immediately after expiry will look like a cache failure.
3. An edge cache layer above Next.js. A CDN or platform-level Cache-Control override can hold a stale copy even when Next.js regenerated. This is the most common culprit when the interval has clearly passed.

How to confirm which one it is

Request the page twice after the revalidate interval has passed and inspect the response headers:

curl -sI https://your-site.com/the-page | grep -iE 'x-nextjs-cache|cache-control|age'

• x-nextjs-cache: MISS — the page was regenerated (or rendered on demand) for this request.
• x-nextjs-cache: STALE — the expired page was served while background regeneration ran; the next request should show fresh content.
• x-nextjs-cache: HIT — served from the ISR cache within the valid window.

Trust x-nextjs-cache over generic Age or Cache-Control headers, since an edge platform can rewrite those. In your platform's function/runtime logs (not the build log), look for regeneration entries for the page path around the time of the request. As a final isolation step, purge the edge cache and re-request: if content updates immediately, the problem was edge-level caching, not your ISR configuration.

On a global revalidation interval

Next.js has no site-wide revalidate setting; each page's value in getStaticProps is independent. A common pattern is to centralize it yourself:

// lib/revalidate.js
export const REVALIDATE_SECONDS = 60;

// in each page
export async function getStaticProps() {
  const data = await fetchFromCms();
  return { props: { data }, revalidate: REVALIDATE_SECONDS };
}

If content must update the moment the CMS changes, time-based ISR is the wrong tool — use on-demand revalidation (res.revalidate('/the-page') from an API route triggered by a CMS webhook), which invalidates the cache immediately instead of waiting out the window.

One detail that would change this advice

The exact revalidate value on the affected page. If it's false, the page never regenerates after build and the fix is a config change, not cache debugging. If it's a short value (e.g., 10–60 seconds) and content is still stale after multiple requests, focus on the edge cache layer.