[Support Guide] Debugging Netlify site builds

Support Support Guides
1

Last reviewed by Netlify Support - October 2024

Note: This article is only about builds within Netlify’s Continuous Integration (CI) environment, as triggered from git commits or from incoming build webhooks. You can learn more in depth about how Netlify builds your site in this article about how our build bots build sites.

Some background

There are a fair number of reasons that a build could fail in Netlify’s CI environment, even if building works locally. Testing locally is always the place to start, and the thing we will recommend to you first when asking for help. Further, you should make sure your build works locally from a fresh clone of the respective branch of your repository. An existing local copy of your code can have local changes that are not reproduced by a git clone, which is how our build network fetches your code, before starting your build.

Note also that there is no “cache” of your build - we cache only your dependencies, NOT the actual files from the last build - those are on our CDN but not available directly during build. The intended use pattern is: “check all the files you need to regenerate your site into git, and let us regenerate the site completely each build from that source code”. It’s an antipattern to commit your node_modules folder or pre-built files already in your publish directory, unless you are NOT having us build your site.

Debugging

The most likely reason for a build failure on Netlify happens when our build environment isn’t configured to match your local environment. There are other reasons as well, which you can read more about here, in our article on troubleshooting build problems, but the version mismatch is the probable reason for problems. This article describes all the possible build settings and versions and how to set them, so it is a great place to start when reviewing our configuration versus your local configuration. Read on for more detailed advice on what to try for your build to get it working!

Since most of our builds use Node.js/Javascript, you should make sure that we build using the same versions of Node.js, npm, and the same Node environment settings that you do locally. To check that, you can simply run node -v in the terminal.

Our current default versions as of April 2024 (though subject to upgrade at any time) are:

  • a NODE_ENV setting of development
  • Node v18 (any version that nvm can install)
  • NPM - Any version available via NPM (default with that version of Node)
  • Yarn v1.22.19 (any version available via their installer) (note that we only install Yarn automatically if you have a yarn.lock file. If you mean to use Yarn but don’t have a yarn.lock in your repository, add Yarn to your package.json so we install it for you before you try to use it :slight_smile: )

You can adjust those versions as follows:

  • Set the Node.js environment with the NODE_ENV variable
  • Set a NODE_VERSION environment variable from the “Build and Deploy” site settings page in our UI - in the “Build Environment” section. The value inside can be anything you would use with nvm (eg 8 or 10.11.2). You can also use a .nvmrc file with this number in it.
  • Set the npm version by setting an NPM_VERSION variable
  • Set a Yarn version with the YARN_VERSION variable

If your build is hanging or terminating abruptly, you could be using too much memory or trying to deploy so many new files we can’t complete the deploy in the default time limits. This post has some more information on those limits and how to troubleshoot.

What next?

In case that doesn’t help you fix your build, the easiest way to debug your build in our environment is to pull down the Docker container that we use as a build image and use it interactively. You must first install Docker (it’s free!) from this website or use your preferred package manager. Then, using a fresh clone of your repo, follow the steps outlined in this doc to use our build container locally: GitHub - netlify/build-image: This is the build image used for running automated builds

Should you have a site that uses plugins - particularly essential ones like gatsby or nextjs - you can and should test a build in our CLI. This will let you see a bit more about what files are generated, and the output is a better representation of what our CI does than the advice above about testing in our docker build image. This workflow is described in this article: Get started with Netlify CLI | Netlify Docs

In case that still doesn’t help, don’t give up! Please start a new thread, link to this one, and tell us the information you gathered while debugging:

  • a link to your most recent deployment attempt in our UI (should start with https://app.netlify.com/sites/…). This will only help the community debug in case your build logs are public, of course. Most public repositories are set with public build logs, and our Support team can by request make your own site’s build logs public even if it’s a private repository.
  • include the specific log line you think the error is in, from that latest deploy you tried to debug and have linked. Make sure you find the root cause error line - Build script exited with Error 1 is a SYMPTOM of some prior error from your build script :slight_smile:
  • give a short, succinct rundown on what you have tried so far and we’ll try to help.
3 Likes