Hi Aman,

I’d check use cache itself first. Even if you did not set export const revalidate = X, use cache has its own cache lifetime behavior. The default profile includes a server-side revalidation window, so it may not behave like “only regenerate when I call revalidateTag.”

That default is described here:

https://nextjs.org/docs/app/api-reference/directives/use-cache

For your case, I’d try to separate three possible triggers:

1. use cache default revalidation Add an explicit cacheLife() profile to the cached function/component so you know exactly when it can revalidate, instead of relying on the default.

2. Bot or prefetch traffic A “couple real visitors” can still create many page reads if crawlers, link previews, uptime tools, or next/link prefetching touch many slug pages. If you have an index page linking to hundreds of dynamic routes, try temporarily setting prefetch={false} on those links and see if ISR reads drop.

3. Hidden requests that do not show up where you expect Cached page hits may not look like normal server logs. I’d use Vercel Observability / Runtime Logs and filter by path, user-agent, and rendering/cache mechanism around the ISR spike time. If needed, add very temporary middleware for /[slug] that logs only non-sensitive fields like path, user-agent, referer, and timestamp.

If the timestamps of ISR reads line up with bot/prefetch requests, then the cache is being touched by real HTTP traffic, just not human visitors. If ISR writes continue for slugs with no matching request at all, then I’d share a small sample of affected paths and timestamps, because that would be much stronger evidence of something internal or unexpected.