An Expo EAS build stuck in queue on the free tier is almost always normal, not broken. Free-tier builds run at lower priority and share a queue, so waits can range from a few minutes to a few hours at peak times, and iOS builds usually wait longer than Android because macOS workers are scarcer. Paid plans are not instant; they give you priority queueing and more concurrency, so shorter waits, not zero. The fastest way to skip the queue entirely is to build locally with eas build --local.
Short answer
A queued free-tier build is waiting its turn, not failing. Expo's free plan includes lower-priority builds, so during busy periods your build can sit in the queue from minutes to a few hours, per Expo's plan documentation. iOS waits are typically longer than Android. Paid plans add priority access and more concurrency to shorten the wait, but they still queue, so they are not instant. Cancelling and re-submitting just sends you to the back of the line. To build without waiting at all, run eas build --local on your own machine, or upgrade for priority.
Why free-tier builds wait longer
Free-tier builds wait longer by design, because Expo prioritizes paid builds in the shared queue. Your free build competes for a limited pool of cloud workers, and paid customers with priority access are served ahead of you, so at busy times your build sits until a worker frees up. This is a capacity and priority arrangement, not a problem with your project.
The wait is usually worse for iOS than for Android. iOS builds require macOS workers, which are more expensive and less plentiful than the Linux workers that build Android, so the iOS queue drains more slowly. If your Android build starts quickly but your iOS build sits, that difference, not a misconfiguration, is why.
How long is the wait? Normal vs abnormal
On the free tier, a queue wait from a few minutes up to a few hours is within the normal range at peak times, and Expo does not promise a fixed start time. Once a build actually starts, it typically runs for several minutes to around half an hour depending on the app. The table below sets expectations.
| Status | Meaning | Free-tier normal | Warning sign |
|---|---|---|---|
| In queue | Waiting for a worker | Minutes to a few hours | Many hours with no start |
| In progress | The build is running | Several minutes to ~30 min | Stuck near the timeout |
| iOS build queued | Waiting for a macOS worker | Often longer than Android | Very long at peak times |
| Errored or canceled | Build failed or was stopped | Not applicable | Re-check your config |
| Finished | The build completed | Final state | (none) |
Treat many hours with no start, especially when other people's builds are moving, as the point to look beyond the normal queue, either at an Expo incident or at upgrading for priority. Within a couple of hours at a busy time, waiting is simply how the free tier works.
Are paid tiers instant?
No. Paid plans reduce the wait but do not eliminate it. What you get by upgrading is priority access in the queue and additional build concurrency, which together mean your builds spend less time waiting and more can run at once, along with higher build-timeout limits. That is faster, not instant.
It is worth being precise, because "instant" is the wrong expectation to set. Even on a paid plan a build enters a queue and waits for a worker; the difference is that you are near the front rather than the back. If you need more parallelism, you can buy additional concurrencies as an add-on, but there is still a queue underneath.
Does cancelling or re-queuing help?
No, and it usually hurts. Cancelling a queued build and starting a new one puts the new build at the back of the queue, so you lose whatever position you had and wait longer, not less. Repeatedly cancelling and resubmitting also burns your monthly free-build allowance for nothing.
The calmer approach is to leave the build queued and let it start when a worker is free. Resubmitting only makes sense if you actually changed something in your project that requires a fresh build, such as fixing a config error. Impatience is the one thing that reliably makes the wait longer.
The fastest fix: build locally
The most effective way to skip the queue entirely is to build on your own machine with eas build --local. This runs the same EAS build process locally instead of on Expo's cloud workers, so there is no queue and no priority tier involved; your build starts immediately, limited only by your own hardware.
There is one platform caveat. A local Android build runs on Linux, macOS, or Windows, but a local iOS build requires macOS, because it needs Xcode and the Apple toolchain. If you are on a Mac, eas build --local works for both platforms and is the quickest way to get an urgent build out while the cloud queue is busy.
Other ways to cut the wait
Beyond local builds, a few habits reduce queue pain. Building during off-peak hours, when fewer developers are queued, often starts faster than building in the middle of a busy workday. Batching your changes so you run fewer builds also stretches your free allowance and reduces how often you hit the queue.
If the wait is a recurring blocker for your work, upgrading to a paid plan for priority queueing and more concurrency is the durable fix, and buying extra concurrency helps teams that run many builds. Which path you choose depends on whether the queue is an occasional annoyance or a daily cost to your team's time.
When it is an Expo incident, not your queue
Sometimes the delay is on Expo's side, not the normal queue. During an incident, workers can be degraded or unavailable, and builds pile up for everyone regardless of tier. Before you spend time changing your setup, check the Expo status page and community channels to see whether others are reporting the same stall at the same time.
If there is an active incident, the fix is to wait or to build locally, not to keep resubmitting. Keep expectations realistic: during an outage even a paid plan will queue, and no local change to your project will help until Expo restores capacity.
Step-by-step: what to do while queued
Act based on how long you have waited and how urgent the build is, rather than resubmitting on impulse. The checklist below gives a clear path.
| Situation | What to do first | Escalate? |
|---|---|---|
| Under one to two hours on free tier | Wait, it is normal | No |
| You need the build now | Run eas build --local | No |
| Repeated long waits | Upgrade for priority queue | No |
| Hours with no start, others fine | Check the Expo status page | If an incident, wait |
| Build errored | Read the logs, fix config, rebuild | No |
The single most effective move for an urgent build is eas build --local, which sidesteps the queue completely. Everything else is about setting the right expectation for the free tier or deciding whether priority is worth paying for.
After the build: scan before you submit
Getting the build out of the queue is only step one; an EAS build that finishes is not automatically ready to ship. The queue and build process do not inspect your app for security problems, so a completed build can still carry an embedded API key, allow cleartext traffic, or leave a debuggable flag on, and those reach users once you submit.
A scanner like PTKD.com analyzes the .ipa or .apk that EAS produces and returns findings ordered by severity and mapped to OWASP MASVS, so you catch security issues before submission. To be clear about the boundary: PTKD has no effect on the EAS queue or build time, and it does not replace the build itself. It checks the artifact the build produces, which is where a security flaw actually ships.
What to take away
- A free-tier EAS build stuck in queue is usually normal: lower priority means minutes to a few hours at peak.
- iOS builds wait longer than Android because macOS workers are scarcer.
- Paid plans give priority and more concurrency, so shorter waits, but they are not instant.
- Cancelling and re-queuing sends you to the back; to skip the queue, run eas build --local.
- After the build finishes, scan the artifact with PTKD.com, because a completed build is not a secure one.
