Second baseline GET:

• X-Vercel-Cache: HIT

• Age: 14788

Then I sent an authenticated request to:

1
POST /api/revalidate-sitemap
2

The endpoint returned:

1
202
2
{"accepted":true,"path":"/sitemap.xml"}
3

The route handler calls revalidatePath('/sitemap.xml') before returning 202.

After the POST, repeated GETs to the exact same immutable deployment returned:

1
Immediate: HIT / Age 14801
2
+2s:       HIT / Age 14804
3
+5s:       HIT / Age 14808
4
+15s:      HIT / Age 14819
5
+30s:      HIT / Age 14834
6

There was no:

• MISS

• STALE

• REVALIDATED

• Age reset

• sitemap route regeneration visible from the client

The observable cache Age continued monotonically across the revalidation POST.

Vercel Runtime Logs

I also reproduced the issue while Runtime Logs were still available.

For:

1
POST /api/revalidate-sitemap
2

Vercel Runtime Logs showed:

• Function Invocation for /api/revalidate-sitemap

• HTTP 202

• Execution duration around 569 ms

• External API call: POST Invalidate Runtime Cache

The target shown by the Vercel UI was:

1
iad1.suspense-cache.vercel-infra.com/v1/suspense-cache/invalidate
2

About 12 seconds later, Runtime Logs for:

1
GET /sitemap.xml
2

showed:

• Cache: HIT

• Cache Key: /sitemap.xml

• no sitemap Function Invocation

So the sequence appears to be:

1
revalidatePath('/sitemap.xml')
2
→ internal runtime cache invalidation request is initiated
3
→ /sitemap.xml is still served as Cache HIT
4
→ cache Age continues increasing
5
→ sitemap route is not regenerated
6

Additional checks already completed

I also verified that:

• the revalidation route is actually invoked

• authentication succeeds

• the correct immutable deployment is used for every request

• the current Preview REVALIDATE_SECRET is present on this deployment

• branch alias switching is not involved

• query parameters / cache-busting are not involved

• browser caching is not involved

• revalidatePath('/sitemap.xml') matches the generated sitemap route

• src/app/sitemap.ts is the route producing /sitemap.xml

• the sitemap and revalidation implementation are byte-identical to an earlier branch where Preview testing previously produced:

1
HIT
2
→ POST 202
3
→ MISS / Age 0
4
→ HIT
5

Questions

Could someone from Vercel help clarify:

1. Is revalidatePath('/sitemap.xml') expected to invalidate a cached sitemap metadata route on Preview deployments?

2. Does the POST Invalidate Runtime Cache event shown in Runtime Logs mean that the internal invalidation request was successfully accepted, or only that it was initiated?

3. Is there a way to confirm whether /sitemap.xml was included in the resolved invalidation target?

4. Why would /sitemap.xml still return:

1
Cache: HIT
2
Key: /sitemap.xml
3

with continuously increasing Age after the invalidation request?

5. Is there any known behavior or limitation involving:

   • Next.js sitemap metadata routes

   • revalidatePath

   • Preview deployments

   • Deployment Protection / Protection Bypass

   • ISR / CDN invalidation

I have intentionally not deployed this change to Production while investigating.

I can provide screenshots of the Runtime Logs showing both the POST Invalidate Runtime Cache event and the later /sitemap.xml Cache HIT if useful.

POST: 2026-08-25 19:08:11.54 GMT+8

first post-POST GET: 2026-08-25 19:08:23.42 GMT+8

The first screenshot shows the revalidation function invoking Vercel's internal cache invalidation call. The second screenshot shows that about 12 seconds later, /sitemap.xml was still served as Cache HIT with cache key /sitemap.xml.