Diagnostics

What the host is doing, right now

Every value on this page comes out of a live response rather than a dashboard. If a panel is empty, the endpoint behind it did not answer - which is itself a result worth having.

Waiting

Serving environment

Round trip from your browser

Ten sequential requests to /api/ping, timed client-side. This includes connection reuse, edge routing and function execution - the number a visitor actually experiences.

Not measured yet.

the panel also refreshes itself when you load the page

Request

Headers as received by the function

Useful when a proxy, a redirect or a caching layer is rewriting something between the browser and the origin. Values that identify you are truncated.

GET /api/echo

Nothing requested yet. This one is manual on purpose - it shows an htmx swap triggered by a click rather than on page load.

Reference

Region codes and where they run

The serving region reported above is a host region code. These map onto the underlying AWS regions, which is what you need when you are checking that a deployment landed where you intended.

iad1: us-east-1 — Washington, D.C. (default)
cle1: us-east-2 — Cleveland
sfo1: us-west-1 — San Francisco
pdx1: us-west-2 — Portland
dub1: eu-west-1 — Dublin
lhr1: eu-west-2 — London
cdg1: eu-west-3 — Paris
fra1: eu-central-1 — Frankfurt
arn1: eu-north-1 — Stockholm
bom1: ap-south-1 — Mumbai
sin1: ap-southeast-1 — Singapore
syd1: ap-southeast-2 — Sydney
hnd1: ap-northeast-1 — Tokyo
icn1: ap-northeast-2 — Seoul
gru1: sa-east-1 — Sao Paulo
cpt1: af-south-1 — Cape Town

A subset of the published region list. Confirm against your host's current documentation before relying on it - region availability changes.

Method

Checking a deployment by hand

The panels above are convenient, but the authoritative check is a request from a terminal. These four cover most of what goes wrong.

Is the new build live?

Compare the deployment identifier before and after a push. It is in the environment panel, and in the x-vercel-id response header on any request.

curl -sI https://usharea.vercel.app/ \
  | grep -i "x-vercel-id\|age\|cache"

Are the redirects right?

Trailing slashes and extension-less URLs are the usual culprits. Follow the chain and check every hop returns what you expect.

curl -sIL https://usharea.vercel.app/about.html \
  | grep -i "HTTP/\|location"

Is the asset cache working?

Fingerprinted assets should be immutable and cached for a year. HTML documents should not be. A second request should report a hit.

curl -sI https://usharea.vercel.app/assets/css/site.css \
  | grep -i "cache-control\|x-vercel-cache"

Can a crawler see the page?

Fetch without a browser user agent and confirm the body still contains the content. If it does not, the page depends on scripting to render - which this one does not.

curl -s https://usharea.vercel.app/ \
  | grep -c "pipeline works"