Live site failing build after timing out at 30mins when very similar staging site is building with no problems in 6 mins

you are now at 45 minutes build time, @adalita . do let us know if your builds go through now!

Hi Perry, thanks for that but it looks like it’s still failing. Could you please bump it up again?

We do think this seems pretty weird because we’ve never needed this much time for builds. Is there anywhere we should be looking to find out what is causing these extended time requirements?

I’m wondering @adalita if you build this site, and the quicker-building site, locally how long the build(s) take. Is there such a discrepancy in build time locally or is it only happening when building in Netlify?

It’s just in netlify…builds and deploys very efficiently locally in both sites

It`s really strange that the assembly takes more than 30 minutes. Recently building site and it took me literally 5 minutes. Definitely, it took longer to figure out how to do it :laughing:

hi there adalita, you are now at 1 hr build time, do let us know it this works now!

Hi @perry it’s still failing :frowning:

Hi, @adalita. When I checked it looked like it was still timing out at 45 minutes. This is the maximum timeout when the build time limit is 30 minutes not 60. (The maximum is the build time limit plus an additional 15 minutes for post processing hence the timeout at 45.)

When I examined the settings, I saw this site was still set for 30 minutes. I’ve just increased it to one hour now. Would you please trigger another build now?

There are a few other things I want to mention.

First and most important

Please change the build command from this:

./build && ps auxw ; false

To this:

./build && ps -ef

Having the build command ending in false means all build return an exit code of 1 and all non-zero exit codes will cause builds to fail. The build command will always fail while this is part of the build command.

The ps auxw change to ps -ef is merely cosmetic as it is serving the same purpose which I assume is debugging to see if there are defunct node background processes. The -ef option change will show parent process ids and I believe that information would be important for troubleshooting the defunct processes (if that turns out to be the case as it could be just a long build instead).

everything else

The second issue is that I want to point out that the ps -ef (or ps auxw if your prefer) is never in the logs. The absence of this debugging output strongly suggests that the build is still running (and that this is not defunct background processes).

The third issue is the build time itself.

Gatsby does cache successful builds and our build system will reuse that cache if it exists. This means that once a build is successful, future build should then be “incremental”. This means that one the cache is created only changed files will require full rebuilds and therefore the builds should be faster … once there is a successful build. A successful build is required first as only successful build caches are reused. I see successful manual deploys but no successful site builds at Netlify for this specific site yet.

To summarize this reply:

  • the build time limit wasn’t increased to 60 before but it has been now
  • the “; false” (including the semi-colon) should be removed from the build command
  • once a build is successful the gatsby caching should improve future site builds at Netlify

Would you please build again and let us know if it succeeds or not?

1 Like

Hi @luke thank you for your detailed response! I’ve just run it again with the changes to the build statement and it still exceeded the build time.

hi there, i am wondering if any of the guidance here might be helpful to you?

we can keep adding build time, but it might be beneficial to see if any optimizations are possible also.

we have now bumped you up to an hour and a half, @adalita ! let us know if that’s enough.

Hi @perry, I’ve already had a look through resource and done what I can. We’re currently trying to reduce the sizes of assets but the folders on the staging environment and live environment are almost identical in size which makes me skeptical that that is causing the issue.

Additionally, as if by magic, one deploy preview built for the site in 17 minutes (Netlify App) but everything since is still getting stuck at the exact same point. I’m letting them run the full 90 minutes and will update you with the results of that but given the deploy preview built quite quickly I’m very confused as to why the site builds should take that much time…

Just updating again, looks like it has magically fixed itself. I ended up reducing the asset folder size by about 300 mb and it did the initial build in around 20 minutes. I’m surprised that made such a difference but hey it’s working now so hopefully it stays that way :slight_smile:

1 Like

fantastic! glad to hear!

Hello!
I have very similar problem and would like to have my page Victoria Dom build time bumped as well please.

Thanks in advance!

hey there indigital, can you be a bit more specific please so we don’t bump the wrong site? we have millions on our platform and the names can sound very similar.

can you share an API ID or exact netlify site name please? thanks!

The api ID is 156db17b-b322-4e9e-8524-fa8996f05406 :slight_smile:
We would love to have one hour build time or more

Thanks so much for reaching out! We have increased your build time limit. If you need anything else, just follow up!

Hello hillary!

We moved our page to new apiID, could you increase the build limit once again please? One hour would be great!

New ID: 1b0969fc-1953-4573-ac8b-90688ff07b75

hi there, we just bumped you up to 1hr. Good luck!