#builds

BestCodes I love this @damilareoo :) I'm curious - why did you name it that?

Damilare Haha!! Thank youuu. It's just a nick name my friends call me lol

Rahmankazemi87 4375 اینا متعلق به کنه ایا

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

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.

Amy Egan Did you try the debugging tips linked above? I'd recommend checking the build settings and output to figure out why the page is missing

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. https://vercel.com/docs/deployment-storage/optimize

Mathieucrcs You're clearly not the only ones... https://community.vercel.com/t/unexpected-build-cpu-charges-without-advance-spending-alerts/50206#post_1

airstairjp I’m the author of the related post linked above. My Build CPU charges also spiked in September: USD 0.58 in May, USD 28.66 in June, USD 1.93 in July, USD 8.19 in August, and USD 402.18 in September (before credits). I haven’t established that unwanted branch builds caused my charges, but I also received no advance warning before they accumulated. I hope Vercel reviews the builds you tried to prevent and gives both cases a path to manual billing review.

Pixelfoundry yeah, we are using vercel since 2023.... once upon a time the story was different.... and we tried to disable the automatic builds, then it kicked back in again... this is very frustrating

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 reproduced your setup on a throwaway project (index.html, about.html, `_markdown/index.md`, `_markdown/about.md`, cleanUrls on). With your rewrites, `curl -H 'Accept: text/markdown'` on `/` and `/about` both returned the HTML. With this, they returned the markdown, and a normal browser request still got HTML: ```json { "cleanUrls": true, "routes": [ { "src": "/", "has": [{ "type": "header", "key": "accept", "value": ".*text/markdown.*" }], "dest": "/_markdown/index.md", "headers": { "Content-Type": "text/markdown; charset=utf-8", "Vary": "Accept" } }, { "src": "/((?!_markdown/).+)", "has": [{ "type": "header", "key": "accept", "value": ".*text/markdown.*" }], "dest": "/_markdown/$1.md", "headers": { "Content-Type": "text/markdown; charset=utf-8", "Vary": "Accept" } } ] } ``` The negative lookahead stops a request for `/_markdown/...` from being rewritten into `/_markdown/_markdown/...`. You can keep your other `headers` block alongside it; the docs say `routes` can now be combined with `headers`, `rewrites` and `cleanUrls`. I also requested `/` with `Accept: text/html` and then `Accept: text/markdown` a few times, and the cached HTML was not handed to the markdown requests.

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.

Pawelmroczek6 6823 https://pmrapiddeliverydopracowana-2.vercel.app/

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

Hali Is anyone 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

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 https://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 all by 6 deployments for my major project with 5 of those being production deploys and one being a preview. I am down to 11 GB now out of 10... I was below 10 earlier today but then opening a PR to a repo pushed me up to 11 GB. So I have gone through and done what the docs say to do, yet it seemed that Vercel was not going and removing the old deploys after I saved the changes, even days after updating.

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.

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 `zmailer` put the new deployment behind the same blocked slot, which is exactly the result you got. That fits your timing. Vercel had two incidents on 18 September, both now resolved, and you can see them on the Vercel status history page: - *Elevated Errors Triggering Deployments*, 20:32 to 21:22 UTC (major) - *Deployment stuck in initializing state*, 21:36 to 22:31 UTC (minor) A deployment that got stuck in `Initializing` during that window does not unstick itself once the incident is over, and it keeps holding the single slot. **What to check** Open Deployments and clear the project filter so you are looking at the whole team, then filter Status by `Building` and `Initializing`. Look for the oldest entry that is not `Ready`, `Error` or `Canceled`, most likely one created on 18 September between roughly 20:30 and 22:30 UTC. **What to do** Cancel that deployment from its three-dot menu, or open it and use Cancel. That releases the slot. Then push a commit, or use Redeploy on the latest `Ready` deployment. Worth knowing: the 45-minute build limit only starts counting once a build is actually running, so a deployment stuck before the build stage can sit there indefinitely. Cancelling is the way out. The **Start Building Now** button is the documented way to force a queued build past the queue, but it belongs to on-demand concurrent builds, which is a paid-plan feature, so it will not help here. **If nothing is stuck** Then check the rate limits, which are also per team on Hobby: 100 deployments per day, 100 per hour, and 60 per five minutes (Limits, Rate limits table). A retry loop reaches the five-minute one quickly, and new deployments are held until the window rolls over. If the team-wide Deployments list shows nothing in `Building` or `Initializing` and you are inside those limits, post the timestamp of your oldest queued deployment and I will take another look.

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.

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: https://v0.app/docs - The v0 expert walkthrough: https://community.vercel.com/t/become-a-v0-expert/5981 - Watch v0 in Action: https://community.vercel.com/live#v0

Ro84833 https://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

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 authorization check is rejecting the deployment-creation request—or suggest a safe diagnostic command that does not modify the current production deployment—I would greatly appreciate it. I can provide additional CLI output or project information if needed.