#builds

Patrick Donahue This is the filesystem check. With cleanUrls: true, /about maps to about.html and / maps to index.html, and the vercel.json docs say rewrites only run after the filesystem: "The source property should NOT be a file because precedence is given to the filesystem prior to rewrites being applied." So for any path that has a real HTML file, the rewrite never fires. Your headers rule still matches though, which is why you can end up with HTML in the body and a markdown content type on top. What worked for me is moving the Accept-header rule into routes, which is evaluated before the filesystem. I re

Izumie Thanks, yeah I've changed rewrite into route and it worked. but agents are accessing different markdown paths like for about.html(with clean url 'about') getting the request at about/_markdown/about.md instead of accessing the page itself.

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/domains/troubleshooting

Hali Is anyone there

Amy Egan The team shipped an update yesterday so your dashboard now reflects each day's deployment storage amount more quickly. If you still need help reducing the amount of storage used, there are some optimization steps that can make a big difference. Linking those below. vercel.com/docs/deployment-storage/optimize

Sweta0519 The new-project test is the most useful thing in your report, and it points at the cause rather than ruling one out. On Hobby the build slot is one per team, not one per project. Build Queues puts it directly: the concurrency queue works from "the number of concurrent build slots available to the team", "Hobby accounts allow one build at a time", and "if all concurrent build slots are in use, new builds are queued until a slot becomes available". So a single deployment that never released the slot parks every later deployment in Queued, across every project on DEVZIKKY. Creating zmail next to

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 Thanks for sharing the project name. That helped me find the deployment. It looks like the 404 error has code NOT_FOUND rather than DEPLOYMENT_NOT_FOUND. That means the index/home page of your project doesn't exist where it was expected. The debugging tips linked above have more info about how to check the deployment output and solve the issue

system While a member of our team prepares to jump in, you might find your answer even faster in our community resources. Official Documentation: v0.app/docs The v0 expert walkthrough: community.vercel.com/t/become-a-v0-expert/5981 Watch v0 in Action: community.vercel.com/live#v0

Ro84833 study-dashboard-two-pied.vercel.app this is the app if you want to see the problem yourself the data and the hours are added before my actions

Amy Egan Hey, James. Appreciate you reaching out about this. The team shipped an update yesterday so your dashboard now reflects each day's deployment storage amount instead of the billing period maximum. I'm linking some Deployment Storage optimization tips in case you still need help reducing the amount of storage used vercel.com/docs/deployment-storage/optimize

James Singleton Hi Amy. Yea after doing some Googling I was able to find stuff about it. It's a little concerning that this was pushed out without an email letting users know. All of a sudden I was getting emails saying that I was using 40 GB of the 10 GB of deployment storage with a single deployment taking up like 30 GB. I started to panic! One issue I ran into is that retention policies were defaulted to 30 days for everything. Even after setting some to 1 week and in some cases 1 day, I wasn't seeing deployments being removed. I had to go through and manually delete deployments. I basically had to delete

James Singleton To add to this, there are projects where the retention is 30 days and I have deployments from January still in my Deployments tab. This project was defaulted to 30 days and I have deployments from Jan-May still there.

Amy Egan It looks like your team hit a 24 hour rate limit and it expired at the expected time. I don't see a current rate limit in effect, but please let me know if you're still having trouble with this

Raouldonati14 6711 Following up on this issue since it has now been several days without a response. The production deployment remains unchanged and operational, and I have intentionally not retried the failed deployment or changed the project configuration. The main issue remains that the authenticated Vercel CLI user is the team OWNER and can successfully access and inspect the existing project, but attempting to create a deployment returns: Error: Not authorized The failure occurs before a deployment ID, build, or Team Activity event is created. If someone from the Vercel team could help identify which author

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: npx vercel --prod That returned this explicit error immediately:

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: Bun as package manager bun install Bun as the runtime used to execute the Next build bun run --bun next build For the Function runtime, Vercel’s Bun config currently uses: { "bunVersion": "1.x" } 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, Ve