#builds

Westborg Found it - solved. Posting in case anyone else hits this. Root cause: vercel.json had an hourly cron (0 ). Hobby accounts only support daily crons. The dashboard/GitHub-triggered deploy pipeline was silently dropping every deployment because of this - no error anywhere in the Deployments list (even with all status filters on) or the Activity log, and even a manually triggered Deploy Hook just returned {"job":{"state":"PENDING"}} and produced nothing. What actually surfaced the real error was deploying via the Vercel CLI directly:

CoffeePuma55644 As an additional test, I also removed Bun as the runtime for the build while keeping Bun enabled for the Serverless Functions. The build completed successfully, but every Server Function immediately returned an Internal Server Error at runtime. The only configuration that currently works reliably for me is to use Bun only as the package manager, while letting Next.js run with the default runtime for both the build and the Serverless Functions. Hopefully this additional information helps narrow down where the issue might be.

Louis Pretty much the same problem here. Since updating to 16.3, `bun run build` (1.3.14) fails on my Railway deployment, although it works locally. Reverting back to 16.2.12 fixed the issue

Ryu Hi CoffeePuma55644, Since you reproduced it with a fresh Next.js 16.3 app, I’d treat this as a compatibility issue between Next.js 16.3 and the Bun runtime path, not just your application code. There are two separate things to separate here: For the Function runtime, Vercel’s Bun config currently uses: and Vercel manages the minor/patch version, so I wouldn’t assume you can force Functions specifically onto 1.3.14 from vercel.json. For the build/install side, Vercel has a KB article for pinning Bun in the Install Command, so you could try this as a narrow test: vercel.com/kb/guide/how-to-pin-a

Ryu Hi Zangyj1971, I don’t think another community member can reliably confirm whether CLI issue #17069 is still present in 58.0.0, but you can separate the documented workflow from the suspected bug pretty cleanly. The documented CLI behavior is that a normal CLI deploy without --prod should create a Preview deployment, while --prod creates Production. So for a fresh linked project, the safest thing to test is: Then check the inspected deployment’s environment/target before using it in any release flow. For Git, Vercel treats the configured production branch as Production and other branches as Pr

Amy Egan Do you see an error message on the commits? That would have more details about what's going wrong. You can also try using the CLI to run vercel build and get more info if there is a configuration error preventing the build

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. 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.

Amy Egan There are a lot of possible causes. I hope you were already able to solve it using the tips shared by the bot. If not, it would be helpful to see the site and code to get a better understanding of what's going wrong in this case. Are you able to share a minimal reproducible example or a publicly accessible URL for the site?

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. 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.

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. 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.

Ryu Hi Solomon, The Functions tab only showing /api/auth/[...nextauth] is not necessarily a problem by itself. Static App Router pages will not always show up there as functions. The more important signal is the exact 404 type and which URL is returning it. I’d separate three cases: Can you test the unique deployment URL from the deployment details page, not just the project alias? If the unique deployment URL works but study-hub-phi-sand.vercel.app returns DEPLOYMENT_NOT_FOUND, that points to an alias/routing association issue. If the unique deployment URL also returns Vercel’s platform DEPLOYMEN

Josh To add, I have a hobby account on Vercel and a Pro account. I was trying to add the personal GitHub to the hobby account and keep the work GitHub on the pro account. Maybe I really only have one account on Vercel (I saw that only 1 GitHub account may be used per Vercel account – the UI is confusing here because then why does it say Add Account)?

Amy Egan Yes, you can connect one GitHub account to a single Vercel account. That is the expected behavior. vercel.com/kb/guide/connecting-teams-with-personal-git-accounts

ADTC FWIW, you can set up GitHub Actions to indirectly deploy your projects into Vercel without connecting your GitHub account. See gist.github.com/ADTC/63ce24ca5a6c306f05d75ad2d6975e93

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. vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Ryu Hi Hero, I’d first separate “Safari is slow to get the document” from “Safari gets the document quickly but renders a blank page for a while.” A quick way to check is to run this in Safari’s console after a slow load, then compare it with Chrome on the same iPhone: If dns, connect, tls, or ttfb is much higher only in Safari, I’d test Safari with iCloud Private Relay/content blockers disabled, and compare Wi-Fi vs mobile data. I’d also compare the custom domain against the *.vercel.app URL. If the Vercel URL is fast but the custom domain is slow, then I’d look at DNS, SSL, or anything proxying

Ryu Hi babakfp, The key clue is this line: After that, the workspace:* error is expected because npm is trying to install a pnpm workspace project. So I’d focus on why Vercel switched package-manager detection, not on the dependency itself. Since this repo is using pnpm@11.9.0, I’d avoid relying only on automatic lockfile detection and try Corepack explicitly. In Vercel Project Settings → Environment Variables, add: Then keep the package manager pinned in the repository root package.json: After that, redeploy without build cache. I’d also double-check the project Root Directory. If the Vercel proj

Ryu Hi Sbullocks, Since static assets work but every function hangs until timeout, I’d separate “Vercel can route to a function” from “your new runtime code is waiting forever.” First, deploy one tiny endpoint that does not import anything shared from the app: If that works, the platform/function routing is fine and I’d look at the changes from the rate-limiting commit: middleware, shared auth helpers, Redis/KV/database clients, external fetches, or env vars that are now awaited before returning a response. If that tiny endpoint also hangs, check whether it is really included in the latest deploym

Ryu Hi Devansh, If those Sentry events cluster around deploy times, I’d treat this as version skew first. With dynamic(() => import(...), { ssr: false }), the browser may not request that CSS/JS chunk until later. If the user loaded HTML/JS from an older deployment, then a new production deployment goes live, that old client can later try to fetch a chunk URL that no longer exists on the deployment it is being routed to. That usually shows up as: A good way to confirm is to check the failed asset request in Sentry or browser devtools: I’d also compare one failed chunk URL directly: If it returns 4

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_ema

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: 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: If you use GitHub’

Tianen Pang check this one 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: 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: github.com/vercel/next.js/issues/89764 For now I’d pin ESLint back to v9 instead of using ESLint 10: If it still keeps ESLint 10 because of the lockfile, do a clean install: 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 writ

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

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: If the init still fails but leaves a partial repo behind, go into that repo and run the failing package directly: or: That should show the real TypeScript / ORM / env-var error instead of only: I’d also check the root package.json after scaffolding. In a Turborepo + pnpm workspace, the packageManager field and lockfile mat

Ryu Hi Senseijayrome, v0 creates its own working branch off main when a chat is connected to GitHub, so if it is stuck at “Create Branch” I’d first separate repo permissions from the v0/GitHub connection state. A few things I’d check: In GitHub, confirm the Vercel/v0 GitHub app has access to AtlasJamaica/atlas-transportation-solutions-jamaica, not just your GitHub account generally. Check whether the repo has branch protection or repository rulesets that block creating or pushing branches matching v0/*. Try creating a test branch manually from main: If that manual push fails, the blocker is probab