Custom domain returns platform NOT_FOUND on READY deployment with valid domain config

Production domain (eopinion.org) has been down for over an hour with a platform-level 404 (x-vercel-error: NOT_FOUND, Server: Vercel), even though the deployment is READY, the build log is completely clean, and the domain shows “Valid Configuration” in Settings → Domains. Posting here because I’ve ruled out everything on my end and I think this is a genuine platform bug rather than something I’ve misconfigured. Free-tier account, so raised a support case too, but wanted to check if anyone’s seen this.

Setup: Next.js 16.2.12 (Turbopack), deployed via vercel --prod CLI, project has multiple custom domains attached (main domain + a short-link domain on the same project).

What happened, in order:

  1. Had a working production deployment, site was live and fine.
  2. Deployed a small change (2 files, CSS classes only) via vercel --prod. Build succeeded, clean route table in the log, deployment READY. eopinion.org immediately started returning NOT_FOUND on every path, including /.
  3. Ran vercel --prod again with zero code changes. Also READY, identical clean build log. This deployment’s own default *.vercel.app URL also returned NOT_FOUND directly, not just the custom domain.
  4. Ran vercel alias set [deployment-url] eopinion.org (and the www variant). CLI reported success for both. Domain kept returning NOT_FOUND afterward.
  5. Checked Settings → Domains: every domain on the project shows “Valid Configuration” with a green check.
  6. Promoted the last known-good deployment (the one that was live and working before step 2) back to production from the dashboard. Confirmed via API that eopinion.org now resolves to that deployment, alias correct, no alias error reported. Still NOT_FOUND.

Step 6 is the part I think rules out everything except the platform itself: a deployment that was proven working, re-promoted back onto the exact domain it used to serve fine, still fails. That’s not a bad build, not a bad alias, not a bad domain config, since all three have now been independently re-verified as correct while the domain still 404s.

Trace IDs from the NOT_FOUND responses, if useful for anyone looking at internal logs:

iad1:iad1::9vq5c-1785651327814-7ddbf1c91267
iad1:iad1::n2sm6-1785652237453-8be041c90b94
iad1:iad1::x5v2g-1785652410456-efdb520318d2
iad1:iad1::vfx9g-1785652665732-acf9296f8be7
iad1:iad1::kf2xn-1785654066067-ab55ffa034d5

Checked status.vercel.com, nothing reported there.

This is a live production site, so any pointers (or a nudge from someone at Vercel who monitors this board) would be genuinely appreciated.

There’s another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes.

A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Following up with more context. I’ve found several other reports on this board describing the exact same fingerprint (control plane shows a correctly aliased, verified, Ready deployment; edge returns X-Vercel-Error: NOT_FOUND regardless):

That last thread has some really solid diagnostic back-and-forth with @ryux1, who correctly identified it as a control-plane/edge-routing desync rather than anything client-side. Tagging you here in case you’re able to look at this one too, the pattern looks identical: alias/verify state is correct, deployment is Ready, but the edge won’t route to it.

To match the evidence format from that thread:

auto

vercel alias ls (relevant lines):
eopinion-jrt8pbdia-chris-h-projects.vercel.app  eopinion.org      (current)
eopinion-jrt8pbdia-chris-h-projects.vercel.app  www.eopinion.org  (current)

Expected deployment: dpl_8VCqzkQWGsSF4HRsLTDBNjXR5ZNK (readyState: READY, target: production)

Failing request:
curl -I https://eopinion.org/
HTTP/2 404
x-vercel-error: NOT_FOUND
x-vercel-id: iad1:iad1::kf2xn-1785654066067-ab55ffa034d5
Timestamp: 2026-08-02T07:01:06Z

I’ve stopped making further alias or domain changes to keep the state stable while this is looked at. Happy to provide anything else that’s useful, this is still down.

Update: worth flagging a detail about this project’s setup that might be relevant.

This project has two apex-level production domains attached: eopinion.org (main site) and eopl.ink (a short-link domain on the same project, redirected via hostname-based middleware logic). I’ve just confirmed eopl.ink is also returning the identical X-Vercel-Error: NOT_FOUND, so it’s not that one domain is healthy and the other broken, they’re both down together.

One thing I noticed throughout: every vercel --prod deploy auto-aliased eopl.ink in its terminal output but never eopinion.org, consistently, across multiple separate deploys. Given Vercel computes a “primary production domain” using a shortest-domain rule (per the docs), and eopl.ink is shorter than eopinion.org, that’s likely why: eopl.ink was being treated as primary and auto-aliased, while eopinion.org needed manual vercel alias set every time.

Not certain this is the trigger, but it’s a genuinely less common setup (two production apex domains + hostname-branching middleware) than most of the single-domain reports in the threads I linked above, so flagging it in case it’s a useful clue for whoever’s looking at the edge routing table.