Can revalidate and tags be used together in App Router fetch?

[maiconsanson]

Summary

I’m using fetch in the App Router with both revalidate and tags.

My first thought was that using them together would update the cache in both situations, but it doesn't.
When using tags together with revalidate, the revalidate timer is ignored and the cache is only updated manually via revalidateTag().

Is there a recommended pattern to combine both time-based cache revalidation and manual tags?

Additional information

await fetch(url, {
  next: {
    revalidate: 43200,
    tags: ['someTag'],
  },
})

Example

No response

[icyJoseph]

Let's see if this does the trick:

• https://nextjs.org/docs/app/api-reference/functions/revalidatePath#relationship-with-revalidatetag

It is possible to use both time based and on-demand tag based invalidation.

[icyJoseph]

How have you tested this? I have this in 15.5.4

export default async function Home() {
  const { uuid } = await fetch("https://httpbin.dev/uuid", {
    next: {
      revalidate: 10,
      tags: ['uuid']
    }
  }).then(res => res.json())

  return (
    <div>{uuid}</div>
  );
}

When I build I see a UUID, then if I wait 10+ seconds, I see a new one, if I hit this endpoint:

import { revalidateTag } from "next/cache";
import { NextResponse } from "next/server";

export function GET() {
  revalidateTag("uuid")

  return NextResponse.json({ ok: 'ok' })
}

Then I also see a new value.

Screen.Recording.2025-09-29.at.19.04.28.mov

[maiconsanson]

I appreciate your time helping with this!

You’re right, it works in development.
I was testing using logging: { fetches: { fullUrl: true } } in next.config, which always showed a cache hit. 🤔

In production on Vercel, the issue appears to be related to the edge cache of the API endpoint (not explicitly set), so the problem probably isn’t with the fetch wrapper after all.

[icyJoseph]

Awesome, please don't forget to mark as answered.

So the problem you observed is that your endpoint (different service) is getting cached?

[maiconsanson]

I still don’t know the source of the problem. Maybe Vercel is automatically caching my API endpoint (even though I haven’t set any Cache-Control header). That’s strange, because according to the docs, it should default to cache-control: public, max-age=0, must-revalidate.

I’ll try manually setting the cache-control header with the same value as the revalidate option on fetch and see what happens.

Is it normal in development to always get a cache hit (even when the revalidate has expired)?

According to Vercel logs, this endpoint is already stale, wtf!

[maiconsanson]

Closing because it's probably a cache issue, and thank you for your help!