Reading the headers your edge actually sends

When a deployment looks wrong, the fastest source of truth is not the hosting dashboard. It is the response headers on a single request, which tell you which build answered, from where, and whether you were talking to a cache.

Start here

curl -sI https://usharea.in/

A HEAD request, all headers, no body. Four of them do almost all the diagnostic work.

The request identifier

x-vercel-id contains the edge locations that handled the request and a unique identifier for it. The region codes at the front tell you the path the request took; the identifier is what you quote when asking anyone else to look at the same request in a log.

Its most useful property is that it changes on every request. If you are trying to work out whether you are seeing a cached response, an identifier that is identical twice in a row is a strong hint that something between you and the origin is answering.

The cache status

x-vercel-cache takes a small set of values, and each one means something specific:

• MISS - not in the cache; it was fetched from the origin and is now stored.
• HIT - served from the edge cache without touching the origin.
• STALE - served from cache past its freshness window while a refresh happens in the background.
• BYPASS - caching was explicitly skipped, usually by a no-store directive or a cookie.
• PRERENDER - served from a pre-generated copy rather than a live render.

The single most common confusion on a new deployment is seeing HIT on an HTML document you just changed. That is not a broken deployment. That is a document being cached with the policy you gave it.

Age

age is the number of seconds since the cached copy was stored. On a fresh MISS it is zero or absent. If you are staring at age: 84213 on a page you edited this morning, you have found your problem without needing anything else.

The two-request rule

A single request tells you very little about caching, because the first request to any edge location is a miss by definition. Always make two.

curl -sI https://usharea.in/assets/css/site.css | grep -i x-vercel-cache
curl -sI https://usharea.in/assets/css/site.css | grep -i x-vercel-cache

Expect MISS then HIT. If the second is still a miss, either the response is not cacheable - check Cache-Control for no-store or a Set-Cookie header that suppresses caching - or your two requests were routed to different edge locations, which the identifier will confirm.

Which region ran the function

Static assets are served from wherever the visitor is. Serverless functions run in a specific region, and that region is a deployment setting, not a property of the visitor. A visitor in Mumbai hitting a function deployed only to iad1 is making a round trip to Virginia, and no amount of CDN configuration will change that.

This is the single most common cause of a site that feels fast in one part of the world and sluggish in another. The diagnostics page reports the executing region directly, and the round-trip probe on the same page measures what it costs you.

A note on measuring from one place

Every number you collect from your own machine describes one network path. It is real, and it is not representative. Before concluding that a host is slow, get a second measurement from a different continent - the difference between "this host is slow" and "this host is far away" is not visible from a single vantage point.