Mac mini M2 build remains queued with no other running builds

[amersamie]

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?

Android (Kotlin)

Steps to reproduce

1. Start MyUMNA’s “iOS Capacitor → TestFlight” workflow on Mac mini M2.
2. Open build fix image url #41.
3. The build remains queued for over 20 minutes without starting any build steps.
   No other builds are running across my apps. The previous build Create LICENSE #40 is canceled. Billing shows only 7 of 500 free macOS minutes used.

Expected results

The queued build should be assigned a Mac build machine and begin preparing the build environment.

Actual results

Build #41 remains in “queued” status. No build steps have started and no build error is displayed.
Please check whether machine availability or an account-level restriction is preventing this build from starting.

Build id (optional)

ID: 6ac786dd546ce6236cec8574

[dtrdic]

Hi @amersamie ,
There’s currently a spike in the build machine load for the pool using Xcode 26.6, which means a large number of users are trying to start builds at the same time.

We’re adding more machines to that pool, so your queued build should start soon.

But if you need your build to start immediately, please change the Xcode version in your yaml file to xcode: 26.5, or xcode: 26.4 as those machines are not busy right now.

Let me know how it goes

[rmartone]

I’m experiencing similar delays on M2 Mac machines (mac_mini_m2). My iOS workflows are explicitly pinned to xcode: "27.0", so this appears to extend beyond the Xcode 26.6 pool.

Over the last few days, turnaround has increased from roughly 10 minutes to over an hour. My Android builds, which also use M2 machines but don’t specify an Xcode version, are affected too.

Is the Xcode 27.0 pool also overloaded, and is there an ETA for restoring normal queue times?

[amersamie]

It started and completed. Thanks!

[JonathanCalhoon]

same thing for me, assuming there is just a huge demand at the moment.

[jaccovaneerden]

I am experiencing the same. Is there any outlook on slowdown of the load, or increase in capacity?

[JonathanCalhoon]

I switched the Xcode version to 26.5 for now and it built immediately. Before that my build was sitting queued for over an hour.

[SoftfmIos]

me too i changed it to 26.5 it worked

[vivekghodasarapanditventures]

Observing the same issue today again.

#Mac mini M2 build remains queued with no other running builds

[vivekghodasarapanditventures]

I switched the Xcode version to 26.5 for now and it built immediately. Before that my build was sitting queued for over an hour.

[ZainCheema]

Switching to 26.5 also worked for me, it was an issue today despite the the website saying the macOS build machine maintenance was complete

[rmartone]

26.5 seems to provide a more reasonable queue time on the M2 boxes even for Android builds that don't use Xcode.

[dtrdic]

It doesn't matter whether you're building an Android or iOS app in this case. You're using a macOS machine for your build, and the Xcode version specified in your configuration determines which pool of build machines is used.

If you've specified xcode: latest in your configuration, or haven't specified an Xcode version at all, your build will use the pool running Xcode 26.6. This pool is currently experiencing high demand, which is why you're seeing longer queue times.

Switching to Xcode 26.5, 26.4, or 26.3, can be a temporary workaround indeed, as these pools currently have available capacity. And your build should therefore start sooner.

But in general, we have seen a significant increase in Codemagic users recently, which has led to higher demand for our build machines.. The team has already ordered additional machines from the vendor, but it will take some time for them to be delivered, installed, and properly configured.

So for now, the best workaround is to switch to a different Xcode version to use a less busy build machine pool.

We apologise for the inconvenience and thank you all for your patience