---
title: "Troubleshooting Build Error: \"Build step did not complete within the maximum of 45 minutes\""
description: Learn common reasons Vercel builds hit the 45-minute limit and how to reduce build times so your deployments stay fast and reliable.
url: /kb/guide/troubleshooting-build-error-build-step-did-not-complete-within-45-minutes
canonical_url: "https://vercel.com/kb/guide/troubleshooting-build-error-build-step-did-not-complete-within-45-minutes"
published: 2026-01-30
last_updated: 2026-08-03
authors: Justin Vitale
related:
  - /docs/deployments/configure-a-build
  - /docs/limits
  - /docs/observability
  - /kb/guide/custom-build-timeout
  - /docs/incremental-static-regeneration
  - /docs/cdn
  - /docs/builds/managing-builds
  - /kb/guide/troubleshooting-sigkill-out-of-memory-errors
  - /docs/functions
install_vercel_plugin: npx plugins add vercel/vercel-plugin
---
<!-- docsgraph:related -->
## Related pages

> **For AI agents:** Follow these links to understand how this page connects to the rest of the Vercel ecosystem. For the full cross-link map (inbound, outbound, prerequisites, and semantic neighbors), see the .graph.md link below.

- [Troubleshoot Build Errors](https://vercel.com/docs/deployments/troubleshoot-a-build?from=related) — Learn how to resolve common scenarios you may encounter during the Build step, including build errors that cancel a depl
- [Builds](https://vercel.com/docs/builds?from=related) — Understand how the build step works when creating a Vercel Deployment.
- [Debug Slow Functions](https://vercel.com/docs/functions/debug-slow-functions?from=related) — Diagnose and fix slow Vercel Functions using CLI tools, logs, and timing analysis.
- [Build System](https://vercel.com/docs/fundamentals/builds?from=related) — Learn how Vercel transforms your source code into optimized assets ready to serve globally.
- [How do I reduce my build time with Next.js on Vercel?](https://vercel.com/kb/guide/how-do-i-reduce-my-build-time-with-next-js-on-vercel?from=related) — Reduce Next.js build times on Vercel by pre-rendering fewer pages at build time, deferring generation with ISR and image
- [Fixing deployments that hang after the build step succeeds](https://vercel.com/kb/guide/fixing-deployments-that-hang-after-the-build-step-succeeds?from=related) — Vercel deployment stuck in "Building" after the build succeeds, with checks and domain assignment pending? The cause is
- [Why aren't commits triggering deployments on Vercel?](https://vercel.com/kb/guide/why-aren-t-commits-triggering-deployments-on-vercel?from=related) — Commits not triggering deployments on Vercel? Walk the diagnostic checklist covering authentication, commit author acces
- [Troubleshooting Build Error: "Serverless Function has exceeded the unzipped maximum size of 250 MB"](https://vercel.com/kb/guide/troubleshooting-function-250mb-limit?from=related) — Learn how to troubleshoot builds failing due to exceeding the maximum function size limit on Vercel.
- [How to stop Vercel Functions from timing out](https://vercel.com/kb/guide/what-can-i-do-about-vercel-serverless-functions-timing-out?from=related) — Vercel Functions that time out usually trace back to a few causes. Learn how Fluid Compute fixes most of them and how to

Full cross-link map for this page: [/kb/guide/troubleshooting-build-error-build-step-did-not-complete-within-45-minutes.graph.md](/kb/guide/troubleshooting-build-error-build-step-did-not-complete-within-45-minutes.graph.md)
<!-- /docsgraph:related -->


When a Vercel build fails with "Build step did not complete within the maximum of 45 minutes," the error almost always indicates too much work is happening during the build itself.

This guide explains why builds time out, how to find the step that's slowing yours down, and how to reduce build-time work so deployments stay fast as your project grows.

## Why builds time out at the 45-minute limit

Vercel enforces a maximum [Build Step](https://vercel.com/docs/deployments/configure-a-build) duration of 45 minutes. The [45-minute limit](https://vercel.com/docs/limits#build-time-per-deployment) is the same on the Hobby, Pro, and Enterprise plans. When a build reaches the limit, Vercel interrupts the Build Step and the deployment fails.

A build that approaches this limit points to one of three underlying problems:

- **Too much work at build time:** The build generates large amounts of content, compiles heavy bundles, or runs validation that doesn't need to happen during deployment.
  
- **Choices that don't scale:** An approach that works at 100 pages or 10 functions gets slower as your project grows to thousands.
  
- **A stalled or missing timeout:** A network call or process hangs and consumes the remaining budget.
  

There's no upper limit on the number of output files a build can create, but builds slow down as that number climbs. Once a project generates 100,000 or more output files, builds can easily exceed 45 minutes. To implement a fix, start by finding what makes up the bulk of the work during the build.

## How to find what is slowing your build

Before changing anything, identify which step consumes your build time. Start with [Build Diagnostics](https://vercel.com/docs/observability) in the Observability section of your dashboard:

1. Open your project in the [Vercel dashboard](https://vercel.com/dashboard).
   
2. Select the **Observability** tab.
   
3. Under **Deployments**, select **Build Diagnostics**.
   

Build Diagnostics shows build duration and resource usage per deployment, helping you spot which deployments got slower and whether the cause was CPU or memory. Read your build logs alongside the diagnostics. Long stretches on "Compiling…", "Installing dependencies…", or repeated function bundling steps each point to a different cause, discussed in the next section.

If a build runs the full 45 minutes before failing, you can force it to fail faster while you troubleshoot with [a custom build timeout](https://vercel.com/kb/guide/custom-build-timeout). Modify your build command to include the timeout command followed by the desired time limit. To create a 15-minute timeout for a Next.js build, your build command would be:

```bash
timeout 15m next build
```

A build that exceeds this duration exits with status code 124, which helps quickly surface the failure. Once you know where the time goes, you can implement a fix.

## Common causes of build timeouts and how to fix them

Build timeouts rarely come from a single cause. The list below runs from most to least common. Start with the likely cause your diagnosis pointed to and work down from there.

### 1\. Too much work happening at build time

Most build timeouts come from generating too much content during the build. Static generation time in frameworks like Next.js, Gatsby, and Nuxt grows with content volume, including pages, routes, localized variants, and CMS entries. As that volume grows, so does build time.

To reduce the work, generate fewer pages at build time and defer the rest:

- **Control which pages pre-render:** For Next.js, use [`getStaticPaths`](https://nextjs.org/docs/pages/building-your-application/data-fetching/get-static-paths) (Pages Router) or [`generateStaticParams`](https://nextjs.org/docs/app/api-reference/functions/generate-static-params) (App Router) to limit the pages generated during the build.
  
- **Generate pages on demand:** You can skip pre-rendering during the build and generate static pages the first time they're requested, then pre-render only for production builds.
  
- **Adopt Incremental Static Regeneration (ISR):** [ISR](https://vercel.com/docs/incremental-static-regeneration) pre-renders a subset of pages at build time and generates the rest on demand. Pages can update without a redeploy. Deferring generation keeps build times stable as your application grows.
  

ISR also serves cached pages from Vercel's [CDN](https://vercel.com/docs/cdn) and persists them in durable storage. This means reducing build-time work doesn't cost you runtime performance.

### 2\. Excessive memory usage

A build that runs out of memory can stall instead of failing cleanly. Vercel's Standard build machines are allocated 8192 MB (8 GB) of memory. When a build overruns allocated memory, it usually throws a SIGKILL or out-of-memory (OOM) error, but in some cases the process isn't killed promptly and runs until it times out.

To fix memory-bound builds:

- **Rule out capacity first:** Move to a larger build machine and redeploy the failing deployment. If it succeeds, memory or CPU was the bottleneck. Enhanced machines double memory to 16 GB, and Elastic machines auto-scale resources based on the build. See [larger build machines](https://vercel.com/docs/builds/managing-builds#larger-build-machines) for the full comparison.
  
- **Reduce memory overhead:** Follow the [guide to troubleshooting SIGKILL and OOM errors](https://vercel.com/kb/guide/troubleshooting-sigkill-out-of-memory-errors) to trim dependencies, optimize assets, and raise Node.js heap limits.
  

A larger machine can also mask a CPU bottleneck, so confirm which resource was constrained in Build Diagnostics before you settle on a fix.

### 3\. CPU-bound compilation and bundling

Builds become CPU-bound when they perform expensive computation, such as bundling large applications, heavy transpilation, image processing, or building large file graphs. This shows up as long builds or a 45-minute timeout, often with logs stuck on "Compiling…", "Bundling…", "Minifying…", or "Generating server/client bundles…".

Large deployments with tens of thousands of outputs can also overwhelm build processing when work runs in unbounded parallelism. Calling `Promise.all()` across every task, or running CPU-heavy operations like `JSON.stringify()` and `Buffer.byteLength()` in parallel, can saturate the CPU.

To reduce CPU pressure during the build:

- **Bound your concurrency:** Batch CPU-heavy tasks or cap parallelism with a library like [p-limit](https://www.npmjs.com/package/p-limit) instead of running everything at once.
  
- **Skip unnecessary source maps:** Avoid generating large source maps unless you need them.
  
- **Add more CPU:** Pro and Enterprise teams can move to larger build machines with more vCPUs, up to 30 on Turbo machines.
  

Adding CPU helps a genuinely compute-heavy build finish sooner, but it won't fix work that shouldn't run during the build at all. Installing dependencies is a common example.

### 4\. Slow dependency installs

When a build can't use its cache, it has to reinstall `node_modules` from scratch, which can dominate build time in large repositories, monorepos, or projects with native dependencies. This shows up as logs stuck on "Installing dependencies…" or every build behaving like a cold build.

Cache misses are the usual trigger. They happen when the cache key changes, such as a different root directory, Node.js version, or package manager, or when many branches build with no warm cache. Large `node_modules` folders, expensive native builds, and heavy `postinstall` scripts that download browsers or build binaries make each install slower still.

To speed up installs:

- **Keep the cache stable:** Hold your package manager and cache keys consistent so builds can reuse the cache instead of reinstalling.
  
- **Remove unused dependencies:** Drop packages you no longer need and move optional tooling out of the build path.
  
- **Skip development dependencies:** Customize the install command to exclude dev dependencies, for example `npm install --only=production`, when your build doesn't need them.
  

Trimming installs keeps each build lean, but validation steps can add as much time. Those often don't belong in the build at all.

### 5\. Quality gates running during the build

Quality gates validate correctness and code quality before changes ship. Running them inside the Build Step is a frequent cause of timeouts, because many are CPU-bound, scale poorly with repository size, and produce nothing that ends up in your deployment.

Common examples include:

- TypeScript type checking
  
- ESLint or other linting
  
- Unit, integration, or end-to-end tests
  
- Storybook builds
  
- Documentation generation
  
- Large code generation, such as OpenAPI clients, GraphQL artifacts, or SDKs
  

These tasks are often redundant with checks you can run elsewhere, and they consume time that should go toward generating deployable output. Continuous integration (CI) systems like GitHub Actions are built for validation work and don't enforce the 45-minute limit.

To move validation out of the build:

- **Run checks in CI:** Move linting, tests, and type checking to CI instead of `vercel build`.
  
- **Keep the build focused on output:** Let the Build Step generate deployable artifacts and nothing else.
  
- **Avoid duplicate checks:** Confirm you aren't repeating a gate that already runs in CI.
  

For Next.js, you can disable ESLint and TypeScript checks during the build when CI already runs them:

```jsx
module.exports = {
  eslint: {
    ignoreDuringBuilds: true,
  },
  typescript: {
    ignoreBuildErrors: true,
  },
}
```

Only disable these checks if the same validation runs elsewhere, so you don't ship code that would have failed a gate. With validation moved out, the remaining build-time cost is often the functions themselves.

### 6\. Too many functions being built

Builds can slow down or time out when a project contains a large number of [Vercel Functions](https://vercel.com/docs/functions). Each function is built independently and keeps its own build cache, so build time grows as the number and size of your functions grow. More functions mean more individual build steps, and larger functions take longer to bundle, optimize, and cache.

This appears in applications with many routes and dynamic segments, and it presents as:

- Build duration rising as you add routes or API endpoints
  
- Logs showing repeated function compilation and bundling steps
  
- Deployments that once succeeded beginning to time out as the app grows
  
- Small code changes triggering long rebuilds because of the number of functions involved
  

To reduce the number of functions your build generates:

- **Consolidate related routes:** Combine related API routes into a single handler rather than one function per minor variation.
  
- **Prefer parameterized routes:** Use dynamic segments instead of many static route files.
  
- **Standardize the runtime:** Use a single runtime when edge execution isn't required.
  
- **Limit shared dependencies:** Avoid large dependencies shared across many functions, since each one carries the cost.
  

Fewer, leaner functions keep bundling time down. The last common cause is different in kind, because it stalls the build rather than overloading it.

### 7\. Stalled network calls

Network requests made during the build can stall the entire build if they have no timeout. This happens when an endpoint can't be reached, a request is blocked, or a service rate-limits you, and the build waits instead of failing.

Builds commonly make network calls to:

- Fetch CMS content
  
- Call internal or external APIs
  
- Connect to databases
  
- Download large assets or binaries
  
- Validate credentials or licenses
  

A call with no timeout, an infinite retry, or a wait for input can stall until the build hits 45 minutes. To keep network calls from hanging the build:

- **Set explicit timeouts:** Add a timeout to every build-time network call, and log when one is hit.
  
- **Bound your retries:** Use a small, fixed number of retries with backoff instead of retrying indefinitely.
  
- **Fail fast:** If an upstream service is unavailable, stop rather than waiting.
  
- **Move fetching to runtime:** Where you can, fetch data at runtime instead of build time, and generate only a minimal set of content at build time.
  

Adding timeouts and bounded retries keeps one slow dependency from consuming your entire build budget.

## How to bypass the build step when a build keeps timing out

Sometimes you need a deployment out the door before you've finished optimizing. You have two ways to get past the Build Step without waiting on a fix.

The first is to build outside Vercel and deploy the prebuilt output. Generate your build artifacts locally, then deploy them directly:

```bash
vercel build
vercel deploy --prebuilt
```

This skips Vercel's Build Step because the artifacts already exist and the 45-minute limit doesn't apply to deployment.

The second option is to add build capacity. Pro and Enterprise teams can use larger build machines, including Enhanced, Turbo, and auto-scaling Elastic machines, the default for new paid teams. More vCPUs and memory help a heavy build finish sooner, though they don't change the 45-minute limit itself.

Treat both of these as ways to stay unblocked while you apply the root-cause fixes above.

## How to prevent build timeouts as your project scales

In most cases, several factors compound build time as your application grows. When builds trend toward 45 minutes, it usually signals one of a few patterns:

- Excessive work happening at build time
  
- Architectural choices that don't scale with project growth
  
- Validation tasks that belong in CI rather than the build
  

The durable fix is to keep the Build Step focused on generating deployable output. Defer page generation with ISR, move quality gates to CI, cache dependencies consistently, and add timeouts to network calls. Monitor build duration in Build Diagnostics so you catch a slow trend before it becomes a failure. If your builds still time out after applying these principles, [contact Vercel support](https://vercel.com/help) for further help.

## Next steps

With build-time work under control, your deployments are ready to ship. [Start a new Vercel project](https://vercel.com/new) to deploy your changes, or [browse the templates](https://vercel.com/templates) for a framework-ready starting point.

## Related resources

- [Managing builds](https://vercel.com/docs/builds/managing-builds)
  
- [Build time per deployment limit](https://vercel.com/docs/limits#build-time-per-deployment)
  
- [Incremental Static Regeneration (ISR)](https://vercel.com/docs/incremental-static-regeneration)
  
- [Troubleshooting SIGKILL and out-of-memory errors](https://vercel.com/kb/guide/troubleshooting-sigkill-out-of-memory-errors)
  
- [How to set a custom build timeout](https://vercel.com/kb/guide/custom-build-timeout)
  
- [Observability](https://vercel.com/docs/observability)
  

## Frequently asked questions

### What is the maximum build time on Vercel?

The maximum Build Step duration is 45 minutes, and it applies equally to the Hobby, Pro, and Enterprise plans. When a build reaches this limit, Vercel interrupts the Build Step and the deployment fails. You can confirm the current value in the [build time per deployment](https://vercel.com/docs/limits#build-time-per-deployment) reference.

### Can I increase the 45-minute build limit?

No. The 45-minute Build Step limit is fixed and can't be raised on any plan. To get past it, reduce the work in your build, such as deferring page generation with ISR and moving quality gates to CI, or deploy prebuilt output with `vercel deploy --prebuilt` to skip the Build Step entirely.

### Do larger build machines remove the build timeout?

No. Enhanced, Turbo, and Elastic build machines add vCPUs and memory so a compute-heavy build finishes sooner, but the 45-minute limit stays the same. They help when a build is CPU- or memory-bound, not when work doesn't belong in the build. See [larger build machines](https://vercel.com/docs/builds/managing-builds#larger-build-machines) for the options.

### Why did my build suddenly start timing out?

Builds usually start timing out because work has grown over time. More pages, routes, functions, or dependencies push build duration up, and a cache miss can turn a fast build into a full cold rebuild. Use [Build Diagnostics](https://vercel.com/docs/observability) to compare recent builds and find which step got slower.