Vercel’s 31 October 2025 changelog added CDN cache telemetry to the Runtime Logs side panel: per-request cache key, cache tags, and revalidation reason. It is the first time cache decisions have sat alongside function traces inside Vercel. The part they do not show is the harder problem: why a response was evicted, which region served it, and which rule caused the bypass.
What does Runtime Logs now show per request?
After the 31 October 2025 changelog, the per-request right-hand panel in Runtime Logs exposes three cache fields: a cache key scoped to each cached-page version, the cache tags attached to that response, and the revalidation reason. Vercel positions all of this as available to every user at no additional cost.
Each field maps to a real mechanism. The cache key is per cached-page version, which matters for ISR and edge-rendered routes where the same path can have multiple valid versions in flight at once. Cache tags are the same tag surface that Next.js revalidateTag writes to, so seeing them in the trace tells you which invalidation group a response belongs to. Revalidation reason is enumerated into three buckets: time-based (TTL expired), tag-based (a tag purge hit that version), and deployment-based (a new deployment superseded the cached response). That taxonomy tells you which of the three invalidation paths fired, which is the part of a cache bug you could previously only guess at.
Before this release, correlating a cache decision with a function cold start in one timeline required separate tools. The change moves cache signals inward, into the same trace view where you already debug function execution and rewrites.
Why does a HIT or MISS not tell you what evicted the response?
A HIT or MISS tells you the outcome of a cache decision. The three new fields, cache key, tags, and revalidation reason, add detail to that outcome, but they do not tell you what evicted the response, and for a low hit rate that distinction is the whole job.
Vercel’s CDN cache is regionally segmented and best-effort, not guaranteed, per the CDN Cache docs. Each region maintains its own cache, so a request served from Frankfurt and a request served from São Paulo do not share state. A path requested once a day can be evicted from the regional cache before the next request arrives, and the resulting cache miss is indistinguishable in the telemetry from one caused by a misconfigured Cache-Control header or a non-cacheable response. The eviction cause is not surfaced. Only the resulting outcome is.
That gap matters because it inverts the apparent promise of the feature. The panel makes the symptom visible at a level of detail Vercel has not offered before: which page version, which tags, which invalidation path. The single question an operator chasing a low hit rate actually needs answered, why is this asset not in the cache when I expected it to be, is exactly the one the telemetry cannot resolve. The debugging work snaps back onto the operator, who has to reason about regional segmentation, request frequency, and eviction pressure without instrumentation for any of them.
Are Runtime Logs cache telemetry and Observability External APIs the same thing?
No. They are two separate surfaces covering two different cache layers, released five months apart, and easy to conflate in the changelog cadence.
The 31 October 2025 Runtime Logs update instruments the CDN cache that sits in front of your deployments, functions, and rewrites. It is per-request event telemetry with the new cache fields attached to each request.
The May 2025 Observability update added external-API caching analytics in the External APIs tab, surfacing hostname-level caching for the third-party APIs your code calls out to, with path-level resolution on Observability Plus. That is aggregate analytics on outbound fetches, not per-request traces on inbound requests.
If your team is debugging why a deployed page is slow, you want Runtime Logs. If your team is debugging why calls to a downstream provider are slow or expensive, you want Observability External APIs. They share a word, “caching”, and almost nothing else, which is worth saying plainly because the two changelogs land close enough together to be mistaken for one feature.
What header inspection is still on the operator?
Until Vercel surfaces eviction telemetry, reproducing a cache decision still means issuing a test request and checking the response. The relevant directives are documented but easy to misconfigure.
To cache a Function response on Vercel’s CDN, the response must carry a Cache-Control header with s-maxage, optionally combined with stale-while-revalidate and stale-if-error, per the CDN Cache docs. proxy-revalidate is not supported. For direct control over caching on both Vercel and downstream CDNs, Vercel exposes a separate CDN-Cache-Control header. Cache-Control headers set in a Function response override any headers defined for the same route in vercel.json or next.config.js, which is a common source of confusion when an operator’s route-level directive appears to be ignored.
A response that omits s-maxage, or relies on the unsupported proxy-revalidate directive, will not cache regardless of what the rest of the configuration says. That kind of misconfiguration produces a cache miss that looks exactly like regional eviction, and the telemetry does not distinguish them.
How long does the cache telemetry stay queryable?
Retention varies by account type, and the “no additional cost, all users” framing describes the surface, not the window, per the Runtime Logs docs. The timeline can span the past hour, the last 3 days, or a custom timespan depending on your plan.
A team investigating an intermittent cache miss from last week may already be past whatever window their account type allows. For anything resembling post-incident cache forensics, the bounded retention is the real constraint, and a miss that reproduces weekly, which is exactly the shape regional eviction tends to take, is awkward to capture without leaving logging on continuously.
How does this stack up against Cloudflare and Netlify?
Vercel’s edge is developer experience: cache decisions inline with function traces, with no extra pipeline to assemble. The cost is the gap between a cache outcome and the rule behind it, which the comparison below does not close for anyone.
| Stack | Cache analytics surface | What you still owe |
|---|---|---|
| Vercel | Runtime Logs CDN cache fields (all tiers) plus Observability External APIs | Manual header inspection for eviction cause; retention window depends on account type |
| Cloudflare | Cache Analytics, Enterprise-only; external-API visibility needs log push, Kong, or Apigee | Enterprise plan, or a separate logging pipeline |
| Netlify | CDN caching, paired with Datadog, New Relic, or Grafana | A third-party observability stack |
| AWS / GCP | CloudWatch, X-Ray, and Cloud Monitoring stitched together | Manual integration across multiple services |
The comparison is less about who has cache telemetry and more about who bundles it into the same console as the rest of the platform. Vercel does. Cloudflare gates the equivalent behind Enterprise. Netlify expects you to bring your own observability vendor. AWS and GCP expect you to assemble one from parts. On bundling and ergonomics, Vercel is ahead, and that is a legitimate advantage for teams already on the platform.
What Vercel does not do, as of this release, is close the outcome-to-cause gap. The cache fields tell you what was cached and how it was revalidated. They do not tell you why an asset is absent. For a regionally segmented, best-effort cache, that gap is where most of the actual debugging time goes. Operators who needed header inspection before this changelog still need it after.
Frequently Asked Questions
What response size and age ceilings does Vercel’s CDN enforce before it refuses to cache?
Function responses above 20MB for streaming functions or 10MB for non-streaming functions are not cacheable, and the maximum cache lifetime is one year regardless of what your Cache-Control requests. A response that crosses either line registers as a MISS with no field in the panel explaining why, which is one more way a cold path can underperform without the telemetry naming the cause.
Does Vercel pass your Cache-Control directives through to the browser and downstream CDNs?
No. By default the CDN strips s-maxage and stale-while-revalidate from the response before it reaches the browser, and only a CDN-Cache-Control directive forwards cache hints downstream. Vercel-CDN-Cache-Control, the header Vercel uses to record its cache decision, never reaches the client or another CDN. A page that caches well at the edge can arrive at the browser with no cache hints, and that mismatch is invisible in Runtime Logs.
How much runtime history do you actually get on each plan for cache forensics?
Hobby retains one hour, Pro one day, and Enterprise three days. Only Pro and Enterprise with Observability Plus get 30 days, capped at 14 consecutive days within a 30-day window. A weekly cache-miss pattern, which is the shape regional eviction tends to take, will not fit inside the lower tiers without continuous logging.
Does the new panel cover every request that touches the CDN?
The cache status values HIT, MISS, STALE, and PRERENDER derive from the x-vercel-cache response header, and the panel logs only requests routed through the Vercel CDN Cache resource filter, which is distinct from the separate filters for Vercel Functions, Routing Middleware, Rewrite, and Redirect. Requests served entirely by a function with no CDN decision attached will not surface cache fields at all.
