⌘K
system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. https://vercel.com/docs/domains/troubleshooting
Rmjabor Thanks. I’ve already gone through the standard domain troubleshooting steps. This does not appear to be a DNS, ownership, SSL, or propagation issue. The inconsistency is internal to Vercel: - `vercel domains inspect` reports the domains on `cifrei-app`; - the project-domain API by project ID reports both domains attached and verified on `cifrei-dre`; - adding them to `cifrei-dre` returns `alias_conflict`; - removing them from `cifrei-app` says they are not assigned there. Vercel’s own diagnostic also indicated stale historical alias references on the production deployment target of `cifrei-app`. Could someone from Vercel please review/reconcile the internal alias/domain attachment state?
system 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. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.
Chris 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): * Ready/Promoted production deployment returns NOT_FOUND on all hostnames * Custom domain 404 NOT_FOUND despite valid config and healthy deployment - CLI evidence * \[Bug\ 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.
Chris 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.
Craiguito This is usually tied to the exact author on the commit Vercel is deploying, not just the email on your GitHub profile. Check the commit that failed: git log -1 --format='%an <%ae>' Then compare that email to the email GitHub shows for that commit on github.com. If the commit uses an old email, a private noreply email that is not tied to your account, or a bot author, Vercel can treat it as an outside collaborator on Hobby. The fix is usually to set git author email locally, make a new commit, and push that: git config user.name "Your GitHub name" git config user.email "your_verified_github_email@example.com" git commit --allow-empty -m "Trigger deploy" git push If you use GitHub private email, use the full noreply address from GitHub settings, not a guessed one. The CLI deploy working makes sense because that path does not rely on GitHub commit author association the same way.
Ryu Hi Abhi, For Hobby projects connected to a private GitHub repo, Vercel needs to verify that the commit author is the Hobby team owner. So I’d check the **actual commit author**, not only the email on your GitHub/Vercel profile. Run this on the commit that failed: ``` git log -1 --format="%an <%ae>" ``` Then open that commit on GitHub and confirm GitHub associates it with your GitHub user. If GitHub shows it as unverified, unknown, a bot, or a different account, Vercel may treat it like an outside collaborator even if you are the only person using the repo. If the email is wrong, set it locally and push a fresh commit: ``` git config user.name "Your GitHub Name" git config user.email "your_verified_github_email@example.com" git commit --allow-empty -m "Trigger Vercel deploy" git push ``` If you use GitHub’s private email setting, use the exact `...@users.noreply.github.com` address shown in GitHub email settings, not a guessed one. Also check: ``` Vercel Account Settings → Authentication → GitHub connected Vercel Account Settings → Emails → commit email added/verified if needed GitHub repo → the commit is attributed to your GitHub user ``` Vercel’s collaboration troubleshooting page explains the Hobby behavior here: https://vercel.com/docs/deployments/troubleshoot-project-collaboration The reason `vercel --prod` can still work is that CLI deploys are authenticated as your Vercel account directly, while GitHub auto-deploys have to verify the Git commit author.
Tianen Pang check this one https://github.com/vercel/next.js/issues/89764#issuecomment-3928272828 for temp fix
ADALIGO The error comes from tooling mismatch not from you **Luknuts56,** just downgrade ESLint and you’re good 👍
Ryu Hi Luknuts56, This one looks like a tooling-version mismatch, not a problem with your `loading.tsx` file. Your `package.json` has: ``` "eslint": "10.0.3", "eslint-config-next": "^16.1.7" ``` and the stack trace is failing inside `eslint-plugin-react` while loading the `react/display-name` rule. There’s an open Next.js issue for this same ESLint 10 error: https://github.com/vercel/next.js/issues/89764 For now I’d pin ESLint back to v9 instead of using ESLint 10: ``` pnpm add -D eslint@^9 eslint-config-next@latest pnpm lint ``` If it still keeps ESLint 10 because of the lockfile, do a clean install: ``` rm -rf node_modules pnpm-lock.yaml pnpm install pnpm lint ``` One more thing: since you’re following a course, I’d avoid using `"latest"` for `next`, `react`, and `react-dom`. The tutorial may have been written for a slightly older version, while `latest` can pull in newer Next/React/ESLint behavior than the lesson expects. So the short version is: downgrade/pin ESLint to v9, reinstall, and rerun `pnpm lint`.
Craiguito I’d isolate the database package before blaming Vercel or the whole template. From a clean folder, try the init with pinned tooling instead of all latest versions: corepack enable corepack prepare pnpm@9.15.4 --activate npx next-forge@latest init If it still creates the repo but fails at @repo/database, cd into the generated project and run: pnpm --filter @repo/database build That should give you the real TypeScript/ORM error instead of Turbo’s wrapper error. The log in the post only says the package build failed, not why. My guess is a version mismatch between the template’s database package and current pnpm/turbo/Node. If the package builds after pinning pnpm and Node 20, it’s a template/tooling drift issue. If it still fails, the exact error from packages/database is the part to chase.
Ryu Hi Segal, The log you posted is still Turbo’s wrapper error, not the actual database package error. I’d isolate `@repo/database` first before treating the whole template as broken. From a clean terminal, try pinning the toolchain instead of using whatever “latest” resolves to: ``` node -v corepack enable corepack prepare pnpm@9.15.4 --activate pnpm -v npx next-forge@latest init ``` If the init still fails but leaves a partial repo behind, go into that repo and run the failing package directly: ``` pnpm --filter @repo/database build ``` or: ``` cd packages/database pnpm build ``` That should show the real TypeScript / ORM / env-var error instead of only: ``` @repo/database:build exited (1) ``` I’d also check the root `package.json` after scaffolding. In a Turborepo + pnpm workspace, the `packageManager` field and lockfile matter for reproducible installs: ``` { "packageManager": "pnpm@9.15.4" } ``` Turborepo documents that field here: https://turborepo.com/docs/getting-started/add-to-existing-repository#add-a-packagemanager-field-to-root-packagejson If the package builds with Node 20 + pinned pnpm but fails with pnpm 10/latest, then this is probably template/tooling drift. If it still fails after pinning, the next useful thing to share is the first actual error from `packages/database`, not the Turbo summary.
system 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. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.
Pauline P. Narvas Could you try the following? Go to your Vercel dashboard → Project Settings → Caches → Purge Everything See if that fixes it!
Anshuman Bhardwaj Hi @shige, thanks for taking the initiative for this with a PR. I'll share it with our team. If you are confident about the PR feel free to make it ready so maintainers can review.
Tadashi Shigeoka Thanks, @anshumanb san! I’ve marked the PR as ready for review. Looking forward to the team’s feedback.
