743772df-221a-467e-b5d5-e460b94d0adb
We are troubled by the title message.
We generate a lot of pages, so that may be one of the causes.
However, it may take 18 minutes to fail or 20 minutes to succeed.
Can we know the correct reason for them?
And how can we speed it up?
Speed > Optimization > Auto Minify
We unchecked everything.
Speed > Optimization > Brotli
We disabled it.
They may be slightly faster.
It succeeded after 20 minutes.
But that may have been a fluke.
Hey,
What step is it failing on during the build?
Also note these settings are for serving content and do not impact your build. I’d definitely recommend keeping Brotli on. Minification may or may not be useful depending on your built assets.
1 Like
Hey, Walshy!
Thanks for your message.
For 94054c3b-774d-4bfc-9b5b-941eef69b908
This is what the log is showing.
Would you say this is a failure because it takes longer to deploy instead of build?
In this case, how should we speed up deployment?
| time | message |
|---|---|
| 09:32:51.764 | Started restoring cached go cache |
| 09:32:51.789 | Finished restoring cached go cache |
| 09:32:51.971 | go version go1.14.4 linux/amd64 |
| 09:32:51.995 | go version go1.14.4 linux/amd64 |
| 09:32:52.000 | Installing missing commands |
| 09:32:52.000 | Verify run directory |
| 09:32:52.001 | Executing user command: nuxt generate |
| 09:34:14.526 | Finished |
| 09:34:14.527 | Note: No functions dir at /functions found. Skipping. |
| 09:34:14.527 | Validating asset output directory |
| 09:34:19.796 | Deploying your site to Cloudflare’s global network… |
| 09:54:24.445 | Failed: an internal error occurred |
| result | job | time |
|---|---|---|
| OK | Initializing build environment | 2s |
| OK | Cloning git repository | 2s |
| OK | Building application | 2m 31s |
| NG | Deploying to Cloudflare’s global network | 20m 4s |
Hey,
A 20 min deploy time is definitely not normal. It looks like you have a lot of content being uploaded and one of the uploads failed. We need to add some retry logic to this. Retrying should fix it. It looks like a lot of the time was just going through all the files, we should look into this a bit more too.
3 Likes
We appreciate your report.
Is it due to us? What can we do to improve it?
Or do we just wait for your response?
We added the following to nuxt.config.js
This increased build time by 1 minute, but decreased deploy time by 3 minutes.
Perhaps it was a fluke. Please let me know if you have a better solution.
generate: {
interval: 20,
},
In 20635b87-76ca-4b40-adcc-b44898f38874, deployments failed in less than two minutes in some cases. This may not be due to the time required.
| result | job | time |
|---|---|---|
| OK | Initializing build environment | 2s |
| OK | Cloning git repository | 2s |
| OK | Building application | 2m 47s |
| NG | Deploying to Cloudflare’s global network | 1m 46s |
| time | log |
|---|---|
| 17:23:44.104 | Started restoring cached go cache |
| 17:23:44.127 | Finished restoring cached go cache |
| 17:23:44.287 | go version go1.14.4 linux/amd64 |
| 17:23:44.308 | go version go1.14.4 linux/amd64 |
| 17:23:44.312 | Installing missing commands |
| 17:23:44.313 | Verify run directory |
| 17:23:44.313 | Executing user command: nuxt generate |
| 17:25:26.579 | Finished |
| 17:25:26.579 | Note: No functions dir at /functions found. Skipping. |
| 17:25:26.579 | Validating asset output directory |
| 17:25:31.859 | Deploying your site to Cloudflare’s global network… |
| 17:27:18.845 | Failed: an internal error occurred |
Can we know the cause of this problem? We would like to see more detailed error messages. We have made various changes that have reduced our deployment time by several minutes. However, the probability of errors has not decreased.
We have already wasted hundreds of hours because of this phenomenon. We want to eliminate this problem as soon as possible.
After our repeated attempts all failed, we re-created our account and started over from the beginning. Then the deployment took only a minute to succeed. We didn’t change anything other than re-creating the account.
It began to fail again.
We set fast build to disabled.
It lengthened the build time, but deploy completed in 1 minute.
This may be temporary, but we will keep this record as it may help someone.
Can you post deployment IDs again since I can no longer track your project.
@Walshy
We are glad you still read my message!
We set fast build to disabled.
This considerably increased the probability of success.
We have mostly succeeded in deploying But we still fail from time to time.
Can you post deployment IDs again since I can no longer track your project.
This is the DEPLOYMENT ID for the failed attempt.
9181b214-bf16-421c-9402-f7516bec1bee
Build log
| action | time |
|---|---|
| Initializing build environment | 2m 2s |
| Cloning git repository | 1s |
| Building application | 6m 37s |
| Deploying to Cloudflare’s global network | 3m 22s |
We have stopped doing fast builds so build times are longer. But it clearly improves the probability of successful deployments. We don’t know the details because we don’t know your inner workings, but we have a feeling that the fast build has something to do with the deploy failures.
I have been reading every message don’t worry!
This is so interesting to me… the fast builds only changes the infra it runs on. The code and everything in the background is the same. Need to dig into it more but not had time yet.
Thanks for the deployment ID. If you could do a fast build again and send that deployment my way too that’d be great.
(Also please don’t delete the deployments sent here so we can keep digging!)
I have been reading every message don’t worry!
We thought you did not see the question that became SOLVED.
We sincerely appreciate your great work.
This is so interesting to me… the fast builds only changes the infra it runs on.
The code and everything in the background is the same.
Need to dig into it more but not had time yet.
We cannot see the details of error message, we just imagine it from the result.
Perhaps it has something to do with the re-creation of the account that was done just prior to that.
Maybe repeated builds and deployments are leaving behind garbage and having a negative impact.
Is it possible that we explicitly clean builds and deploys?
Thanks for the deployment ID.
If you could do a fast build again and send that deployment my way too that’d be great.
(Also please don’t delete the deployments sent here so we can keep digging!)
I see. So if we delete the failed builds, you will be untraceable.
We can either leave it or note the new failed build ID.
We understand that this problem is difficult to find the cause of because the probability of occurrence is not 100%.
We enabled Fast builds and checked and this time it worked.
If the result is like this every time we will be very satisfied.
Ah…We have two projects that are very similar but failed to deploy on the other.
Deploy Success
6192a529-8422-4536-a096-27785ac90c95
Build log Fast builds Beta
| action | time |
|---|---|
| Initializing build environment | 2s |
| Cloning git repository | 1s |
| Building application | 2m 37s |
| Deploying to Cloudflare’s global network | 2m 5s |
Deploy Failed
40eb3340-5672-4e6d-be64-0d30be886309
Build log Fast builds Beta
| action | time |
|---|---|
| Initializing build environment | 2s |
| Cloning git repository | 2s |
| Building application | 2m 36s |
| Deploying to Cloudflare’s global network | 2m 56s |
1 Like
We keep Fast build enabled, but then it doesn’t fail at all.
Have you made any modifications?
We would like to know if it is due to our configuration change or yours.
If this continues to build and deploy successfully, then Cloudflare pages really is a great service!
Ah. Still sometimes Cloudflare Pages failed to deploy.
Deployment success rate is better than before.
We have not.
Looking at your last few deployments, I see the last 4 of 5 have succeeded. The failed deployment (c1d5ea95-8cdb-4663-991f-7bc345c06dba) failed due to an upload fail same as before. If we add retry logic here it should make your success rate basically 100% (hopefully).
This deployment looks to have had 6083 files being uploaded (either due to being modified or new files). A little understandable why this sometimes fails 
We will work on improving this though don’t worry.
We sincerely thank you for your continued research and we look forward to working with you in the future.
We have 6083 files and you say this is the likely cause of the deployment failure? Does our reducing the number of files reduce the probability of deployment failure?
Do you exit without retrying when a deployment fails? Is there any way to get us to retry it?
We will not know that the deployment failed until we see the results in the console. Is there anything we can do to re-hook the build if the deployment fails?
Yep for sure. The internet is fragile and often little hiccups happen to cause a request to fail. There’s 6100 chances for that to happen. Reducing the files would definitely help.
Right now yes, we’re at this minute literally talking about retries. It’s definitely something we should address sooner rather than later.
Good question. You could use a GitHub Action to watch the deployment and retry it. I have an action which you could use for that: GitHub - WalshyDev/cf-pages-await: Wait for your Cloudflare Pages builds to finish!
We are working on it though!
We need them all. But maybe we can put together some files. We’ll see how we can do that.
I understand. We will wait for you to be able to retry.
We have no experience with GitHub Action, but will look into it you have created.
We have the hook API call build when the information is updated, but sometimes it seems to return status 304. Does that mean deploy failure? Can we repeat it until a status of 200 is returned?
We tried it and it failed to deploy many times even when it returned success instead of 304. That seems to be irrelevant.