Update with more diagnostic evidence, in case it helps anyone else hitting this or a Vercel team member scanning the thread:

Ruled out: build failure. Pulled the actual build log for the deployment (not just the status badge) - completely clean: dist/assets/index-qL9nJRs3.js built successfully, "built in 4.68s", "Build Completed", "Deployment completed". No errors, correct bundle hash, matches what I confirmed is served correctly from the deployment's own dedicated preview URL.

Ruled out: hidden failed/queued deployments. Checked the full deployment history with the status filter expanded to 7/7 (Ready, Error, Building, Queued, Initializing, Canceled, Blocked). Every deployment across dozens of commits is Ready. Nothing hidden.

Ruled out: stale build cache. Just did a fresh Redeploy with "Use existing Build Cache" unchecked (fully clean build, new deployment, Ready in about 16s). The production domain's served bundle is completely unchanged afterward - still the exact same old hash it was serving before any of this, confirmed via a fresh no-store fetch (x-vercel-cache: MISS, age: 0) immediately after the new deployment went Ready.

What Vercel's own dashboard says vs reality: the deployment's "Assigning Custom Domains" pipeline step shows a green checkmark and explicitly lists the production domain as an assigned domain. The Domains panel on the deployment overview lists it directly too. So the control plane believes the domain is correctly aliased to this deployment. But the domain itself, fetched fresh, still serves a different older deployment's bundle.

This really does look like the edge/alias propagation bug several others in the Related Topics below have hit recently. At this point I've tried manual Promote and manual Redeploy twice, once with cache and once without. Both succeeded and both left the domain unchanged. Would appreciate any pointer from someone who's seen this resolve, or confirmation this needs Vercel-side intervention.

I checked and did appear to get the correct asset briefly, but on refreshing it changed and I see you pushed a new deploy

Do you still see old data with this new deployment too? If so can you try a different browser to narrow down where the issue is coming in? Generally this should just work and the times where it gets weird are usually around Skew Protection where you're using a tab that was open prior to the new deployment and haven't hard refreshed yet, in which case we do route assets back to the prior version to keep it intact

Thanks for looking into this, Jacob. To your specific question: yes, still old data with the new deployment too, confirmed just now.

I tested exactly what you suggested - opened a brand new browser tab that had never loaded this site before (so no prior deployment to be pinned to, and document.cookie was completely empty, confirmed via console). Fetched the production domain fresh from that tab: still got the old bundle (assets/index-Br3OKlbL.js), not the current deployment's bundle.

Given that's a genuinely cookie-less, first-load tab, it seems like this rules out the simple case of Skew Protection routing a specific already-open client tab back to its original deployment - there was no "prior tab" for it to be routing back to here. That said, your note that you personally saw the correct asset briefly before it changed makes me wonder if this is inconsistent across edge regions/PoPs rather than uniformly stuck - i.e. some edge locations have the current deployment cached/routed correctly and others don't yet. Does that match what you're seeing on your end, or is there another angle worth checking?

Follow-up with harder evidence, including two things that go beyond what the dashboard can show:

1. Same deployment, two URLs, two different bundles. Took the newest Ready deployment's own dedicated preview URL directly (bypassing the custom domain entirely) and it correctly serves the new bundle (assets/index-qL9nJRs3.js, all recent features present). The custom domain, fetched fresh in parallel, still serves assets/index-Br3OKlbL.js. Same commit, same "Ready" deployment, two different URLs, two different bundles served.

2. The domain's alias metadata is already correct, and it's still not served. I checked what the domain is actually aliased to via `vercel alias ls` (CLI) and the deployment's own dashboard page (Domains panel). Both agree: the domain is aliased to a deployment that HAS the current content. No CLI/dashboard disagreement. The alias record is right. The edge just isn't honoring it.

3. Ran `vercel cache purge --type cdn` for this project (confirmed correct project scope first). Purge reported success. Re-fetched the domain immediately after with cache: 'no-store' — still assets/index-Br3OKlbL.js, unchanged.

4. The stale response's own `Date` header doesn't move. Every fetch of the domain, across this entire thread (spanning many hours and multiple purge/redeploy/promote attempts), returns a `Date` response header of Sat, 15 Aug 2026 13:57:56 GMT — identical to the second — while `x-vercel-cache: MISS` and `age: 0` keep claiming it's a fresh response. A real cache miss regenerates `Date` from current server time on every request by definition. This isn't just stale content being re-served; the entire response, headers included, appears to be a frozen snapshot being replayed verbatim, which is why the CDN purge didn't touch it — whatever's serving this isn't going through the layer that purge reaches.

At this point I've tried: manual Promote, manual Redeploy (with and without build cache), and now a CDN purge via CLI. All succeeded on their own terms and none moved the served bundle by a single byte. Metadata (dashboard + CLI) agrees on the correct target; the edge disagrees with both. Given the frozen Date header specifically, I don't think there's another self-service lever left to pull here — this looks like it needs a manual/forced purge on Vercel's side of whatever's holding that snapshot. Appreciate any escalation path you can point me

to, Jacob.

@jacobparis Quick bump with the clearest signal yet, plus something that unblocks me in the meantime.

The strongest evidence: every fetch of monets-garden-in-the-sky.vercel.app, over several days now and across multiple purge/redeploy/promote attempts, returns an identical `Date` response header — Sat, 15 Aug 2026 13:57:56 GMT — down to the second, every time, while `x-vercel-cache: MISS` and `age: 0` claim it's fresh. `Date` is supposed to be regenerated from the server's live clock on every response, cache hit or miss. A header that never moves across days of real requests means the entire response (not just the bundle) is a frozen snapshot being replayed — which is also consistent with why `vercel cache purge --type cdn` (ran it directly via CLI, reported success) didn't touch it.

To sidestep the freeze rather than keep waiting on it: I added a brand new alias to the same project - monets-garden-app.vercel.app, pointed via `vercel alias set` at the exact same currently-Ready deployment. It serves the correct current bundle immediately, with a live/current Date header that actually advances between requests. Same project, same deployment, same account - only the domain string is different, and that's the one thing that makes it work. That pretty much confirms this is scoped specifically to whatever's cached against the monets-garden-in-the-sky.vercel.app alias, not the project, the deployment, or the account.

Could you (or someone on the infra side) force-clear whatever's holding that specific domain's edge/alias cache? Happy to provide the project ID or any other identifiers you need. I'll keep the new alias as a working fallback for now, but I'd like to get the original domain back since it's what my family actually has bookmarked.