Does Vercel serve stale ISR content beyond the revalidation interval under high concurrency?

Short answer: yes, and there is no concurrency threshold you can tune. Vercel's ISR model is stale-while-revalidate: once the revalidate interval expires, the next request triggers a background regeneration and every request that arrives during that regeneration window receives the previously cached (stale) version, whether that's one request or a thousand. There is no documented or observable request count at which Vercel switches to serving fresh content synchronously.

What's confirmed vs. what's assumed

Confirmed, well-established behavior:

• After the interval expires, the first request gets x-vercel-cache: STALE and kicks off background regeneration.
• Concurrent requests during the regeneration window also get the stale copy. This is by design — it protects your origin/render function from a thundering herd.
• Once regeneration completes, subsequent requests return the fresh version (HIT).

Not confirmed, and likely not knowable from outside:

• Any specific concurrent-request threshold that changes this behavior. Vercel does not publish one, and none of the observable headers expose one.
• Whether behavior varies by region (iad1 vs fra1), plan tier, or edge load. Anecdotal variation exists, but since the internals are undocumented, treat any observed difference as unstable — it can change without notice.
• Whether the revalidation interval length itself influences stale-serving. The interval controls when revalidation triggers, not how concurrent requests are handled during it.

Can you force fresh generation?

Not per-request. Your options are coarse:

• revalidate: 0 (or SSR) — disables ISR caching; every request renders fresh at the cost of latency and compute.
• On-demand revalidation via res.revalidate('/path') (Pages Router) or revalidatePath/revalidateTag (App Router) — purges the cache entry so the next request regenerates. This is the right tool when freshness matters more than the stale window.
• Manual purge from the Vercel dashboard or CLI.

No request header (including Cache-Control: no-cache from the client) forces a fresh render for an ISR page; Vercel's edge cache controls that decision.

How to verify on your own deployment

1. Deploy a page with getStaticProps returning { props: { ts: Date.now() }, revalidate: 10 }.
2. Request it once to populate the cache, then wait more than 10 seconds.
3. Send a burst, e.g. k6 run or wrk -t4 -c100 -d10s https://your-app.vercel.app/page.
4. Check response headers: x-vercel-cache: STALE with the old timestamp confirms stale serving during regeneration; a later HIT with a new timestamp marks the end of the window.

Two caveats: run the test against a staging deployment in the same region as production, and don't build correctness on whatever threshold you think you observe — the internals are undocumented and can shift. If your application cannot tolerate a stale window at all, the reliable answer is on-demand revalidation or SSR, not hunting for a concurrency limit that isn't exposed.