Hi, thanks for the reply. I just tried redeploy without cache but the issue still exists. (Actually all the previous redeployments are without cache.)
By the way, I also noticed that the failed deployments builds significantly longer than normal. It used to be 2~3 minutes, but the failed builds take 10~13 minutes.
It’s two days now and still the builds fail with no reason (with or without cache).
Maybe the solution is to simply move this web app out to other platforms if Vercel is unreliable. So for anyone reading this in the future, I’m a paying user and this is my personal account for side projects. Will move everything out as soon as possible.
Don’t bother, I’m moving everything off Vercel. I paid hundreds of dollars to Vercel, and now my project was unable to build for days, you told me the company was “on a company offsite” like that’s somehow my issue.
After a week, you finally thought, “Oh yeah, maybe I should ask about the content and size.” I know you probably just work there, so this isn’t personal, but come on, there’s clearly a huge cultural issue at this company. I’d seriously suggest anyone to get out while you can, whether you’re a customer or an employee.
We received following error in your project while building:
This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
It sounds like you have a large files in Git Repository and the cloning is failing from GitHub end. Instead of vercel build and vercel deploy --prebuilt step, can you try running vercel deploy instead? it should bypass cloning and deployment should work