#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 اینا متعلق به کنه ایا

Jacob Paris This looks great, I like that you copied the shadcn theming shape so it feels more familiar. Your included themes do look more like recolors though, it would be cool to have more variety like tweakcn.com

Aniket Pawar Thanks Jacob, theme builder is underway and will be released soon.

Amy Egan so cute

Amy Egan I also use GitHub's email privacy option and haven't run into this problem. Are you sure the metadata is configured correctly? Commits just need to be seen as belonging to your GitHub account if you've already connected it to Vercel

tallneil Not sure - it's possible something wasn't configured correctly, but I decided to disable email privacy in github, and that solved the problem.

Amy Egan glad you found a workaround! lmk if you decide to turn it back on and need help with configuration

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

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

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 https://community.vercel.com/t/what-to-do-when-your-team-is-paused-or-blocked/45069

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.

Amy Egan Hey @niwdecr-2830, thanks for sharing the job id. The logs suggest that the problem is related to cron job configuration, not an incident or bug. > "Hobby accounts are limited to daily cron jobs. This cron expression (0 * * * *) would run more than once per day. Upgrade to the Pro plan to unlock all Cron Jobs features on Vercel." This is the kind of configuration issue that prevents a build from starting. You should see the same error message on the GitHub commit. You can also use Vercel CLI to run a local build to get detail error info, which I find really helpful for debugging.

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.

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: ``` { "status": "error", "reason": "deploy_failed", "message": "Hobby accounts are limited to daily cron jobs. This cron expression (0 * * * *) would run more than once per day. Upgrade to the Pro plan to unlock all Cron Jobs features on Vercel." } ``` Fix: changed the cron schedule to run once a day instead of hourly, pushed, and deployments immediately started working again via git push as normal. Would be great if this validation error could also surface in the dashboard / on git-triggered deployments and Deploy Hook responses, instead of only appearing via the CLI - it cost a lot of time to track down since every other signal (Git connection, GitHub App permissions, deploy hook response) looked healthy. ````