Stop Overusing revalidatePath — Fix Stale Next.js Caches with Tags Instead

If you're running ISR on a Next.js App Router app past a certain traffic level, revalidate: 3600 stops being a caching strategy and starts being a bet you'll lose. Either your content goes stale for up to an hour, or you swing the other way and call revalidatePath() on every update — which rebuilds far more than you actually changed.

There's a middle path, and it's been sitting in the App Router the whole time: hierarchical cache tags.

Why time-based revalidation breaks down

Time-based ISR is a blind countdown. You set revalidate: 3600 and Next.js re-fetches on a schedule, whether or not anything actually changed. Two things go wrong here.

First, stale reads. Someone updates a post in the CMS, hits publish, and the edge keeps serving the old version for up to an hour because there's no relationship between "this content changed" and "purge this cache entry." Second, when the countdown does hit zero on a high-traffic page, every concurrent request theoretically wants a fresh copy at once — a thundering herd against your origin database.

revalidatePath('/blog/[slug]') looks like the fix, but it's a sledgehammer. It purges the entire route tree, which means every component on that page re-fetches from the database, including the ones that had nothing to do with whatever changed. For a full layout redesign, that's actually what you want. For "an editor fixed a typo in one article," it's wasted database load for no reason.

Tag every fetch, not every page

The fix is assigning fine-grained tags at the fetch level instead of purging by path. Give each entity two tags: one for its collection, one for the specific item.

// src/lib/api/articles.ts
export interface Article {
  id: string;
  slug: string;
  categoryId: string;
  title: string;
  content: string;
}

export async function getArticleBySlug(slug: string): Promise<Article> {
  const res = await fetch(`https://api.yourdomain.com/articles/${slug}`, {
    next: {
      tags: [
        'articles',                 // collection tag: revalidate all articles
        `article:slug:${slug}`,     // specific item tag
      ],
      revalidate: 86400, // fallback, in case a webhook is ever missed
    },
  });

  if (!res.ok) throw new Error('Failed to fetch article');
  return res.json();
}

Notice the revalidate: 86400 didn't disappear — it's still there as a 24-hour safety net. Tags handle the fast path; the time-based fallback covers the case where a webhook silently fails and nobody notices.

The webhook route that actually purges things

Your CMS (or admin dashboard, or database trigger) needs somewhere to send "this changed" events. A single authenticated route handler covers it:

// app/api/revalidate/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { revalidateTag } from 'next/cache';

const WEBHOOK_SECRET = process.env.REVALIDATION_SECRET_TOKEN;

export async function POST(request: NextRequest) {
  try {
    const authHeader = request.headers.get('x-revalidate-secret');
    if (!WEBHOOK_SECRET || authHeader !== WEBHOOK_SECRET) {
      return NextResponse.json({ message: 'Unauthorized' }, { status: 401 });
    }

    const body = await request.json();
    const { tag, tags } = body;

    if (tag) {
      revalidateTag(tag);
    } else if (Array.isArray(tags)) {
      tags.forEach((t: string) => revalidateTag(t));
    } else {
      return NextResponse.json({ message: 'Missing tag or tags payload' }, { status: 400 });
    }

    return NextResponse.json({
      revalidated: true,
      purgedTags: tag ? [tag] : tags,
      timestamp: new Date().toISOString(),
    });
  } catch (error) {
    return NextResponse.json({ message: 'Error revalidating cache', error }, { status: 500 });
  }
}

Don't skip the secret header check. This endpoint can invalidate cache for your entire site — treat it like any other privileged mutation, not a throwaway utility route.

You don't need to build stampede protection yourself

Here's the part that's easy to over-engineer: worrying about a thundering herd once a popular page gets invalidated. Next.js already handles this.

When revalidateTag() fires, the first request after invalidation triggers a background rebuild while the stale page keeps serving. Every other concurrent request during that window gets the same stale copy — nobody else touches the origin. Once the rebuild finishes, the cache swaps atomically at the edge. Zero origin downtime, zero manual locking.

That's the actual payoff of tags over revalidatePath(): not just precision, but knowing the framework's stale-while-revalidate behavior is already doing the concurrency work you'd otherwise reach for Redis locks or request coalescing to solve.

When revalidatePath is still the right call

Tags aren't a universal replacement. If you've reworked the layout itself — new components, restructured data dependencies, a redesign — revalidatePath() is simpler and correct, because you genuinely do want everything on that route rebuilt. Reach for it there, not as the default for single-entity updates.

Choosing a strategy

For anything with an editorial workflow or frequent single-record updates — articles, inventory, product listings — hierarchical tags are the default that should've shipped from day one. Time-based revalidation is a fallback, not a plan, and revalidatePath() is for when you actually mean "everything here changed."