Answering right now
Running on Vercel
iad1 · linux/x64 · node v24.18.1 · pid 4 · up 6m 12s
Every value below is marked with the moment it was decided. That is the only reliable way to tell a fresh deploy from a cached copy of the last one.
- Build
- Request
- Browser
Built
16:17:53
2026-08-20 UTC
Frozen into the bundle
This request
16:56:30
2026-08-20 UTC
Produced by the server
Build
Baked in when the bundle was compiled
- Commit
- 13f606f
- Branch
- main
- Message
- Measure data-cache age instead of inferring it from latency The /data page decided a read came from cache when it returned in under 25ms. That threshold was calibrated against a home connection, where the API takes 100ms+. Deployed to Vercel it fell apart: from iad1 the API answers in ~25ms and the platform's data cache is itself a network hop costing ~10ms, so the two were never far enough apart to separate. The no-store panel -- which cannot be cached, by construction -- was reporting itself as a cache hit. Read the age of the response instead. Every server stamps a Date header on what it sends, and Next stores response headers in the data cache alongside the body, so on a hit that header is the moment of the original fetch rather than of this request. Latency measures distance; Date measures provenance. This also makes the page self-checking. The no-store panel is now a control that must always read zero, so a broken measurement is visible on its face rather than silently producing plausible numbers. Wa
- Built with
- node v24.19.0
- Snapshot from
- next build
Machine
Read from this process on this request
- Host
- Vercel
- Region
- iad1
- Hostname
- 169.254.6.53
- NODE_ENV
- production
- Port
- 3000 (default)
- Memory
- 114 MB resident of 2279 MB · 2 cpu
- Time zone
- UTC
- target
- production
- url
- deployment-probe-97hy83rg7-mohamedkhaled4053s-projects.vercel.app
- deployment
- dpl_F3FxeVCXD3URmxvEgzwZHF81Tbso
How each page renders
Open each one, reload a few times, and watch its timestamp. Platforms disagree about caching more than anything else, and this is the fastest way to find out what yours actually did.
Static
Timestamp never moves until you rebuild
Prerendered once at build time and served as a file.
ISR
Timestamp moves at most once every 20 seconds
Cached, then regenerated in the background after it goes stale.
Dynamic
Timestamp moves on every reload
Rendered from scratch for each request.
Caching pages and caching the data inside them are separate systems. The data cache runs the same experiment against a public API.
What reached the app
9 of 11 watched headers
- host
- vercel.0foq.com
- x-forwarded-for
- 216.73.216.41
- x-forwarded-proto
- https
- x-forwarded-host
- vercel.0foq.com
- x-real-ip
- 216.73.216.41
- x-vercel-id
- cle1::v8w7x-1787244990813-a2379ceb370d
- x-vercel-ip-country
- US
- accept-encoding
- gzip, br, zstd, deflate
- user-agent
- Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
Environment
Anything key-shaped is masked before it renders
- APP_LABEL
- set, but empty
- APP_SECRET_TOKEN
- set, but empty
- AWS_REGION
- us-east-1
- NODE_ENV
- production
- TZ
- :UTC
- VERCEL_BRANCH_URL
- deployment-probe-git-main-mohamedkhaled4053s-projects.vercel.app
- VERCEL_CACHE_HANDLER_MEMORY_CACHE
- 0
- VERCEL_DEPLOYMENT_ID
- dpl_F3FxeVCXD3URmxvEgzwZHF81Tbso
- VERCEL_DEPLOYMENT_KEY
- wuh••••••U=
- VERCEL_ENV
- production
- VERCEL_FLUID
- 1
- VERCEL_GIT_COMMIT_AUTHOR_LOGIN
- moh••••••53
- VERCEL_GIT_COMMIT_AUTHOR_NAME
- moh••••••ed
- VERCEL_GIT_COMMIT_MESSAGE
- Measure data-cache age instead of inferring it from latency The /data page decided a read came from cache when it returned in under 25ms. That threshold was calibrated against a home connection, where the API takes 100ms+. Deployed to Vercel it fell apart: from iad1 the API answers in ~25ms and the platform's data cache is itself a network hop costing ~10ms, so the two were never far enough apart to separate. The no-store panel -- which cannot be cached, by construction -- was reporting itself as a cache hit. Read the age of the response instead. Every server stamps a Date header on what it sends, and Next stores response headers in the data cache alongside the body, so on a hit that header is the moment of the original fetch rather than of this request. Latency measures distance; Date measures provenance. This also makes the page self-checking. The no-store panel is now a control that must always read zero, so a broken measurement is visible on its face rather than silently producing plausible numbers. Wa
- VERCEL_GIT_COMMIT_REF
- main
- VERCEL_GIT_COMMIT_SHA
- 13f606f86fb368cf279f7282f03918cae0f09a61
- VERCEL_GIT_PREVIOUS_SHA
- set, but empty
- VERCEL_GIT_PROVIDER
- github
- VERCEL_GIT_PULL_REQUEST_ID
- set, but empty
- VERCEL_GIT_REPO_ID
- 1340580259
- VERCEL_GIT_REPO_OWNER
- mohamedkhaled4053
- VERCEL_GIT_REPO_SLUG
- deployment-probe
- VERCEL_HANDLER
- /var/task/___next_launcher.cjs
- VERCEL_IPC_PATH
- /tmp/vercel-3113507859.sock
- VERCEL_PARENT_SPAN_ID
- f02e98d052f920ff
- VERCEL_PROJECT_ID
- prj_GqHnhTBdMapBRpERDl4wNF3kukdj
- VERCEL_PROJECT_NAME
- deployment-probe
- VERCEL_PROJECT_PRODUCTION_URL
- www.0foq.com
- VERCEL_REGION
- iad1
- VERCEL_TARGET_ENV
- production
- VERCEL_URL
- deployment-probe-97hy83rg7-mohamedkhaled4053s-projects.vercel.app
- VERCEL_VDC_REMOTE_CACHE_ENABLED
- 1
Endpoints
Timed from your browser, so this includes the network between you and the deployment.
- GET
/api/health—What a load balancer probes
- GET
/api/info—Build and runtime facts as JSON
- GET
/api/echo?region=test&cache=bust—Headers your proxy added on the way in
- POST
/api/echo—Whether POST bodies survive the hop
- GET
/api/upstreams—Server-side egress, on demand