Cache issue in Next JS 15 with App Router

[Gavrushuk]

Version Next JS: 15.5.2
Using App Router

Since we're using Next.js 15+, not all fetch requests are cached by default. Because of that, we explicitly added caching options:

For the posts list:

{ next: { tags: ["posts"] }, cache: "force-cache" }

For a single post:

{ next: { tags: [`post-${slug}`] }, cache: "force-cache" }

We also use a revalidation API endpoint where we trigger the following after a post is published, edited, or deleted:

revalidateTag("posts");
if (slug) {
  revalidateTag(`post-${slug}`);
}

The issue is that when a post is updated, the data is revalidated, but when navigating through our site—switching between pages such as the news feed (static), post page (dynamic), and home page (static)—we see inconsistent data.

On some pages, the post title is updated; on others, it still shows the old version. Sometimes the title on the single post page is outdated while the lists are already updated.

If we keep navigating between links, after about ~15 minutes, everything eventually syncs and shows fresh data. Additionally, if we manually refresh a page twice, only then does it display the updated content.

We're trying to decrease staleTime in the Next.js config from 5 minutes to 1 minute for static pages, but it hasn't helped.

Maybe someone has experienced this issue and successfully fixed it. Any suggestions or insights would be greatly appreciated.

Thank you!

[KippieG]

The inconsistent data you are seeing after revalidateTag is caused by two separate caching layers that are easy to conflate:

1. Server-side fetch/route cache

This is what revalidateTag invalidates. When your revalidation endpoint fires, the Next.js server discards the cached fetch result and will re-fetch from your data source on the next incoming request. This works correctly in your setup.

2. Client-side Router Cache (in-memory)

This is the culprit. Next.js keeps an in-memory cache of RSC payloads in the browser for pages the user has already visited. Even after the server has fresh data, the browser may serve the previously cached page RSC payload on navigation — without hitting the server at all. This explains:

• Seeing stale data on some pages but not others (depends on which pages are cached in the router)
• Needing ~15 minutes for everything to sync (that is the default staleTimes expiry for static pages: 300 seconds)
• Needing to refresh twice (first load hits router cache, explicit reload forces a full network request)

Fix

Configure staleTimes in next.config.ts to reduce how long the client-side router cache holds on to static page payloads:

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  experimental: {
    staleTimes: {
      static: 30,  // seconds — was 300 (5 min) by default
      dynamic: 0,  // seconds — keep at 0 for dynamic routes
    },
  },
};

export default nextConfig;

Alternatively, if a page shows content that changes after mutations (like your post list and post detail), call router.refresh() right after the mutation/revalidation fires on the client:

import { useRouter } from "next/navigation";

const router = useRouter();

async function handlePublish() {
  await fetch("/api/revalidate", { method: "POST" });
  router.refresh(); // forces the router cache to be bypassed for the current page
}

router.refresh() does not do a full page reload — it re-requests the current route from the server and updates the router cache in place, so the user stays on the same page but sees fresh content immediately.

Summary

Layer	Invalidated by	Your issue?
Fetch / ISR cache	revalidateTag / revalidatePath	No — working correctly
Client Router Cache	router.refresh() or staleTimes expiry	Yes — this is the cause

Reducing staleTimes.static to something like 30–60 seconds, or calling router.refresh() after publishing/editing, should resolve the inconsistency immediately.

[MahdiJDS]

A few things stand out here.

Since you're already using:

cache: "force-cache"
next: { tags: [...] }
revalidateTag(...)

and the underlying data eventually becomes consistent, this doesn't sound like a simple tag invalidation failure.

My first suspicion would be that you're dealing with multiple cache layers, not a single stale fetch.

In App Router, a page can be affected by:

1. Data Cache (fetch cache)
2. Full Route Cache (static rendering output)
3. Router Cache on the client

It's possible that revalidateTag("posts") is correctly invalidating the Data Cache, but you're still navigating through a previously cached route payload on the client.

A few questions that may help narrow it down:

• Are the pages showing stale data using generateMetadata()? If so, is metadata fetched separately from the page data?
• Are you using unstable_cache() anywhere?
• Does the stale title appear only after client-side navigation (<Link />) or also after a direct URL visit?
• If you call router.refresh() after publishing/updating a post, does the inconsistency disappear?

One thing I'd try as a diagnostic step is temporarily adding:

export const dynamic = "force-dynamic";

to one of the affected routes.

I wouldn't keep that in production, but if the issue immediately disappears, you've confirmed that a route-level cache is involved rather than the tag revalidation itself.

Another thing worth checking is whether the list page and the post page are actually sharing the same source of truth. I've seen cases where:

revalidateTag("posts")

invalidates the list query,

but the individual post page is populated through a different fetch, cache wrapper, CMS SDK cache, or generateMetadata() fetch that isn't associated with the same tag.

The fact that:

• navigating repeatedly eventually fixes it,
• refreshing twice fixes it,
• and everything converges after some time,

makes me think Router Cache or Full Route Cache is the more likely culprit than revalidateTag() itself.

I'd be interested to see:

• your revalidation endpoint,
• the fetch code for both the list and detail page,
• and whether the stale content is in the page body, metadata, or both.

That would help determine which cache layer is actually serving the outdated data.