Queued builds automatically cancelled after ~300 minutes when triggering

[abhishekmirajkar-get-sides]

If you are looking for help, please confirm the following...

• I confirm I have searched the Docs, Codemagic Sample Projects, and GitHub Discussions.
• I confirm the software versions on my local computer match the ones in CI environment (e.g. Xcode version, Gradle version). See here
• I confirm I am able to do a fresh clone of the repository and build the project on my local computer.

Which mobile framework are you using?

Flutter (Dart)

Steps to reproduce

1. We trigger ~120 builds via the Codemagic REST API as part of a planned bulk release.
2. Each build takes approximately 15 minutes.
3. Total required compute time is around 30 hours.
4. All builds are triggered immediately and enter the queue.
5. After approximately 300 minutes (5 hours), the builds that are still in queue (~30–40 builds) are automatically cancelled.

Expected results

Queued builds should remain in the queue until they start execution.

Since this is a planned bulk release, we expect builds that are waiting due to concurrency limits to eventually start once previous builds finish, without being automatically cancelled after a fixed time period.

Actual results

Builds that stay in queue for approximately 300 minutes are automatically cancelled.

This happens consistently when triggering ~100+ builds via API.

The cancelled builds are typically the ones that were still waiting in queue and had not started execution yet.

We are planning to increase the number of apps in the coming days, so this behavior makes bulk releases unreliable for us.

Build id (optional)

No response

[icarusdust]

Hi @abhishekmirajkar-get-sides, how many concurrencies does your team have currently ? have you considered increasing it?

[abhishekmirajkar-get-sides]

We are currently running with a single concurrency. Increasing concurrency would not really solve the issue, because the total cumulative build time is around 30 hours.

Even if we increase concurrency, the overall timeout remains the same, and we would still run into build failures due to the total execution time.

Is there any way that we can increase the default time out?

[icarusdust]

The main idea is to decrease the number of queued builds to let your other queued builds start before hitting the queue limit.

[abhishekmirajkar-get-sides]

Unfortunately, that won't help us, because we have around 600 apps planned for the pipeline, that means around 1200 builds
We automate starting the build via APIs, but if we got to decrease the number of builds, that is inefficient for us, plus we cannot predict the build time, which might lead to more issues.

[icarusdust]

I was referring to decreasing the number of queued builds by adding more concurrency, so they can start earlier.

[icarusdust]

I'm closing this thread for now, but please feel free to reply.