Last updated by Netlify Support in April 2024
The only universal answer to this is: it varies. 
More detail would probably be helpful, right? Below we explain which factors affect the lengths of builds on Netlify
One key factor is the site itself. Larger sites will take longer to build than smaller ones, and things like images and video can impact this (if those assets need to be downloaded or processed during build).
Another factor is the static site generator (SSG) being used (if any). The performance of SSGs varies widely. If the site takes a long time to build locally, that will also carry over to Netlify.
Also, the systems which handle the site builds are a shared resource (amongst Netlify users). When the network is under heavy load, newly scheduled builds will be queued instead of beginning immediately. When the load is high on the build system, and when utilizing our our Starter or Pro team plans, it is normal for builds to queue for up to fifteen (15) minutes.
Also when the load is high, it is possible that your build will be competing for scarce CPU/memory resources. Your build is guaranteed only 4 CPUs and 8 GiB memory. This is could be less than your local systems, so times will not likely match your local unless you use a very efficient SSG like hugo.
Finally, what happens in the situation where many git push actions occur in a short time window while there is queuing in the build network? (And it’s a good question!)
Answer: each push will trigger a deploy with Netlify but only the first and last actually build & deploy.
Here is a more detailed explanation. Let’s imagine you run a git push five times in a few minutes. Let’s also pretend your build takes 10 minutes to complete, so the last 4 deploys are queued.
So, what happens? Well, all five pushes will create deploys in your deploy listings page in the Netlify admin UI, and all will show as ‘building’ in the UI. But when the first deploy completes, the intermediate builds will all change to the status ‘skipped’ and then Netlify will build the last (most recent) deploy. We don’t waste our time or yours publishing builds that will be overwritten immediately.
Three more considerations around time to deploy, rather than just build:
- once built, we must UPLOAD any changed files! The more you change, the longer it takes to upload. This article talks in detail about reducing the number of unintentional changes in your builds
- This article runs through all the potential optimizations you could make around what you build, when you build, and how you build it.
Regardless, if you notice unusually long queuing times for builds, something might be wrong! Please let us know in the comments below.