Troubleshooting Build Errors

You can troubleshoot build errors that occur during the Build step of your deployment to Vercel. This guide will help you understand how to investigate build failures and long build times.

You can use the following views on your dashboard to troubleshoot a build:

• Build logs - the console output when your deployment is building which can be found under the Deployment Status section of the Project's Deployment page.
• Resources tab - the functions, middleware, and assets from your deployment's build.
• Source tab - the output of the build after the deployment is successful. This can also be accessed by appending/_src to the Deployment URL

You can navigate to these views from the Deployment page by clicking on theSource tab, theResources tab or theBuild Logs accordion as shown below.

If your build fails, Vercel will report the error message on theDeployments page so that you can investigate and fix the underlying issue.

In the following we show you how to look up the error message of your failed build.

Build logs provide you with an insight into what happened during the build of a deployment and can be accessed by:

1. From your Vercel dashboard, select the project and then theDeployments tab
2. Select the deployment. When there are build issues you will notice an error status next to deployment name

1. On the errored deployment's page, you will see a summary of the error in the preview section. In theDeployment Details section, expand theBuilding accordion to expand the logs.There are situations wherebuild logs are not available, in this scenario the error will be presented in the UI instead.

2. Scroll down in the build logs until you find a red section where the keyword"Error" is mentioned.It can be mentioned once or multiple times.In many cases, the last mention is not indicative like in the example below where it saysyarn run build exited with 1.If you look a few lines above, you will see an additional error which in this case indicates where the problem is with a link for more details. Sometimes, an error may not be mentioned in the lines above but the output will often help you identify where the problem is.

It is recommended to build your project on your local machine first (the build command varies per project) before deploying on Vercel. This will catch issues specific to your code or to your project's dependencies. In the example above, when the commandnpm run build (that runsnext build) is run in the local console for a Next.js project, the error happens after building locally.

Builds can fail without providing any build logs when Vercel detects a missing precondition that prevents a build from starting. For example:

• An invalidvercel.json configuration was committed
• When usingIgnored Build Steps
• Commits were made from a contributor that is not ateam member

In this case, you cannot access theBuilding accordion described above, and instead, Vercel will present an overlay that contains the error message.

Sometimes, your Deployment Build can hit platform limits so that the build will be cancelled and throw a corresponding error that will be shown in the Build logs. Review the limits below in case you run into them.

Every Build is provided with the following resources:

For Hobby customers, these limits are fixed. Pro and Enterprise customers can purchaseEnhanced or Turbo build machines with extra CPUs, larger memory, and storage. Exceeding the memory or disk space allocations limits cancels the build and triggers a system report in yourBuild logs, identifying memory and disk space issues.

By default, the system generates this report only when it detects a problem. To receive a report for every deployment, setVERCEL_BUILD_SYSTEM_REPORT=1 as anenvironment variable.

This report helps you detect hidden Out of Memory (OOM) events, and provides insights into disk usage by breaking down the sizes of your source code,node_modules, and output, and flagging files over 100 MB. The input size in the report corresponds to the size of your checked-out repository or files uploaded by CLI. Thenode_modules size represents the total size of allnode_modules folders on disk.

Review the below steps to help navigate this situation:

• Review what package the error is related to and explore the package's documentation to see if the memory allocation can be customized with an install or Build command
• If no package is specified, look into reducing the amount of JavaScript that your Project might be using or find a more efficient JavaScript bundler
• Review what you are importing in your code such as third-party services, icons and media files

The total build duration is shown on the Vercel Dashboard and includes all three steps: building, checking, and assigning domains. Each step also shows the individual duration.

A Build can last for a maximum of 45 minutes. If the build exceeds this time, the deployment will be canceled and the error will be shown on the Deployment's Build logs. If you run into this limit, review thisguide that explains how to reduce the Build time with a Next.js Project.

The maximum size of the Build's cache is 1 GB. It is retained for one month and it applies at the level of eachBuild cache key.

It is not possible to manually configure which files are cached at this time.

You may come across the following Build-specific errors when deploying your Project. The link for each error provides possible causes of the error that can help you troubleshoot.

• Missing Build script
• Recursive invocation of commands
• Pnpm engine unsupported

A 'module not found' error is a syntax error that will appear at build time. This error appears when the static import statement cannot find the file at the declared path. For more information, seeHow do I resolve a 'module not found' error?

The first Build in a Project will take longer as the Build cache is initially empty. Subsequent builds that have the sameBuild cache key will take less time because elements from your build, such asframework files and node modules, will be reused from the available cache. The next sections will describe the factors that affect the Build cache to help you decrease the Build time

Vercel caches files based on theFramework Preset selected in yourProject settings. The following files are cached in addition tonode_modules/**:

Note that the framework detection is dependent on the preset selection made in theBuild settings. You should make sure that the correct framework is set for your project for optimum build caching.

At the beginning of each build, the previous Build's cache is restored prior to theInstall Command orBuild command executing. Each deployment is associated with a unique Build cache key that is derived from the combination of the following data:

• Personal Account orTeam
• Project
• Framework Preset
• Root Directory
• Node.js Version
• Package Manager
• Git branch

Let's say that under your accountMyTeam, you have a projectMySite that is connected to your Git repositoryMyCode on themain branch for the production environment. When you make a commit to themain branch for the first time, you trigger a build that creates a production deployment with a new unique cache key. For any new commits to themain branch ofMyCode, the existing Build cache is used as long asMySite is underMyTeam.

If you create a new Git branch inMyCode and make a commit to it, there is no cache for that specific branch. In this case, the lastproduction Deployment cache is used to create a preview deployment and a new branch cache is created for subsequent commits to the new branch.

If you useVercel functions to process HTTP requests in your project, each Vercel Function is built separately in the Build step and has its own cache, based on theRuntime used. Therefore, the number and size of Vercel functions will affect your Build time. For Next.js projects, Vercel functions are bundled to optimize Build resources as describedhere.

At the end of each Build step, successful builds will update the cache and failed builds willnot modify the existing cache.

Since development dependencies (for example, packages such aswebpack orBabel) are not needed in production, you may want to prevent them from being installed when deploying to Vercel to reduce the Build time. To skip development dependencies, customize theInstall Command to benpm install --only=production oryarn install --production.

Sometimes, you may not want to use the Build cache for a specific deployment. You can invalidate or delete the existing Build cache in the following ways:

• Use theRedeploy button for the specific deployment in the Project'sDeployments page. In the popup window that follows, leave the checkboxUse existing Build Cache unchecked. SeeRedeploying a project for more information.
• Usevercel --force withVercel CLI to build and deploy the projectwithout the Build cache
• Use an Environment VariableVERCEL_FORCE_NO_BUILD_CACHE with a value of1 on your project to skip the Build cache
• Use an Environment VariableTURBO_FORCE with a value oftrue on your project to skip TurborepoRemote Cache
• Use theforceNew optional query parameter with a value of1 whencreating a new deployment with the Vercel API to skip the Build cache