Canonical Alias Returns NOT_FOUND

Canonical Production alias returns platform NOT_FOUND while control plane points to current Ready deployment

Summary

I attempted to create a Vercel Support case, but this project is currently on the Hobby plan and dedicated Edge Network support is unavailable.

Our current/latest Production deployment is Ready, and the canonical project alias metadata points to it. However, dynamic requests to the canonical hostname return Vercel platform NOT_FOUND before reaching the Next.js runtime or Proxy, while the static asset /icon.svg succeeds.

The exact generated deployment URL is protected by Vercel Authentication as configured.

We found no application-code, Next.js route, root-directory, alias ownership, or Deployment Protection explanation for this behavior. We are not retrying promotion, redeploying, or changing the domain while waiting for guidance.

Exact Deployment

https://beauty-contract-production-jtc4ql8y9.vercel.app

  • Created: 2026-07-14T11:59:37Z

  • Status: Ready

  • Target: Production

  • Current/latest Production deployment: Yes

Canonical Domain

https://beauty-contract-production.vercel.app

The alias metadata points to the exact deployment above.

Assignment timestamp:

2026-07-14T12:00:16Z

Reproduction

  1. Request canonical /login.

  2. Observe HTTP 404 with Vercel platform NOT_FOUND and no redirect.

  3. Confirm that the request does not reach the Next.js runtime or Proxy.

  4. Request canonical /icon.svg.

  5. Observe HTTP 200.

  6. Inspect the Vercel project, deployment, and alias metadata.

  7. Confirm that the canonical alias points to the current/latest Ready Production deployment.

Expected Result

Canonical /login should reach the deployed Next.js application.

Actual Result

Canonical dynamic routes receive Vercel platform NOT_FOUND before reaching the application runtime.

The protected API also returns platform 404 instead of the expected application-level 401 or 403 response.

The canonical static icon succeeds.

Safe Request Evidence

Route UTC timestamp Status x-vercel-id
Canonical / 2026-07-15T08:12:50.446Z 404 sin1::4mlvb-1784103169585-b4ea9a4794a7
Canonical /login 2026-07-15T08:12:51.668Z 404 sin1::cb6g6-1784103170295-749bff8142ac
Canonical /dashboard 2026-07-15T08:12:52.066Z 404 sin1::fc2cx-1784103170495-a1a3e8e24138
Canonical /icon.svg 2026-07-15T08:12:52.154Z 200 sin1::ls8pr-1784103170585-ff336b5c2ee4
Canonical /api/contracts/drafts 2026-07-15T08:12:52.237Z 404 sin1::nkhhr-1784103170671-663bd5d06e75
Exact deployment /login 2026-07-15T08:12:52.373Z 302, then 200 after two Protection redirects sin1::w56m9-1784103171009-1aec733bae8c

Troubleshooting Completed

  • Validated the project and linked workspace.

  • Validated Ready status, Production target, and current/latest Production assignment.

  • Confirmed that no newer Ready Production deployment exists.

  • Confirmed that one canonical alias record points to the exact deployment.

  • Found no duplicate or wrong-project domain assignment.

  • Confirmed successful Next.js build, /login, expected dynamic routes, and Proxy.

  • Confirmed the correct root directory.

  • Confirmed there is no basePath, rewrite, or redirect configuration explaining the 404.

  • Confirmed Deployment Protection mode is all_except_custom_domains.

  • Confirmed that authentication on the exact deployment URL is expected and does not explain the canonical platform 404.

  • Executed exactly one promotion attempt. It returned a conflict and was not retried.

  • Corrected promotion-status parsing and confirmed there is no active promotion operation.

  • Confirmed current assignment with:
    operation_not_found_current_assignment_confirmed

  • Reproduced the canonical edge behavior with UTC timestamps and safe request IDs.

Request to Vercel

Could a Vercel team member please inspect or escalate the canonical project-domain edge assignment?

The control-plane alias state points to the current Ready Production deployment, but dynamic canonical requests receive Vercel platform NOT_FOUND before reaching the Next.js runtime.

Please investigate whether the canonical Production domain has stale or inconsistent edge-routing state.

If customer-side action is required, such as detaching and reattaching the domain, please provide the exact safe steps before I make any configuration changes.

Please do not rebuild the application, disable authentication or Deployment Protection, reset the project, or delete the domain without diagnosis.

Attachments

I have attached the complete evidence package as four sequential PNG images:

  • VERCEL_EVIDENCE_01.png

  • VERCEL_EVIDENCE_02.png

  • VERCEL_EVIDENCE_03.png

  • VERCEL_EVIDENCE_04.png

The original Markdown evidence and attachment inventory are available through another secure upload method if needed.

No secrets, environment values, cookies, user data, internal project/team IDs, or private signed URLs are included.

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.

Thank you. I followed the 404 debugging guide and verified the relevant items.

Additional results:

  • Canonical domain configuration status:
    Alias is assigned to the current/latest Ready Production deployment.
    No duplicate, wrong-project, pending, or invalid marker was found.
    Canonical dynamic routes still return Vercel platform NOT_FOUND.

  • Trusted IPs or access-group restriction affecting this domain:
    None detected / not applicable on the Hobby plan.
    Standard Deployment Protection affects the generated deployment URL, not the canonical Production domain.

  • Blue 404 information box:

    • Code: NOT_FOUND
    • ID: sin1::cb6g6-1784103170295-749bff8142ac

Previously confirmed:

  • The current Production deployment is Ready.

  • /login and the expected dynamic routes exist in the Next.js build.

  • Root Directory and Framework configuration are correct.

  • There is no basePath, rewrite, redirect, or output-directory issue explaining the behavior.

  • Canonical alias metadata points to the current/latest Ready Production deployment.

  • Canonical dynamic routes return Vercel platform NOT_FOUND before Next.js runtime or Proxy.

  • Canonical /icon.svg returns HTTP 200.

  • The exact deployment URL responds through Deployment Protection as configured.

This still appears to be a canonical alias control-plane versus edge-routing mismatch rather than an application-level missing route.

Could a Vercel team member review the supplied x-vercel-id values and UTC timestamps or escalate this internally?

I found several recent Community reports with the same behavior, including:

  • “Production aliases return 404, while the underlying deployment serves fine on its hashed URL”

  • “Edge 404 (NOT_FOUND) despite valid alias — possible control plane / edge routing desync”

  • “Custom domain returns 404 NOT_FOUND on fra1 edge despite fully valid configuration”

  • “Custom domain 404 after moving to a new project via API”

The matching pattern is:

  • Deployment is Ready

  • Hashed deployment URL works or reaches Deployment Protection

  • Canonical .vercel.app and/or custom aliases return platform NOT_FOUND

  • Alias metadata correctly points to the current Production deployment

  • Requests do not reach the application runtime

  • Redeploying, reassigning aliases, and removing/re-adding domains did not resolve the issue in several cases

This suggests the issue may affect newly provisioned aliases or edge-routing state beyond a single project.

Could a Vercel team member compare these reports and escalate them together for investigation of stale or missing edge alias provisioning?