Elevated Linux worker queue times
A fix was deployed at 2:50pm PT/5:50pm ET. The job queue has been running as expected. The root cause of this incident is that a new version of a cache needed more vCPUs than it was given, and we have increased the CPU count as the immediate fix along with additional monitoring for CPU usage on these cache instances.
The latest update from Expo.
State
Resolved
Started
60 d ago
2026-09-02 21:44 UTC
Lasted
21 min
until 2026-09-02 22:05 UTC
Worst impact
Degraded
Timeline
3 updatesInvestigating
8 min 39%
Identified
13 min 61%
Updates
Times in UTCAs posted by Expo
A fix was deployed at 2:50pm PT/5:50pm ET. The job queue has been running as expected. The root cause of this incident is that a new version of a cache needed more vCPUs than it was given, and we have increased the CPU count as the immediate fix along with additional monitoring for CPU usage on these cache instances.
We have determined that some of our package caches are under high load, and this is causing elevated build times and in turn causing higher Linux worker queue times. We are currently working on a fix. In-progress builds are continuing to complete and enqueued builds are continuing to be processed.
Queue times are elevated for Linux workers for EAS Build and Workflows. Android build jobs may be delayed. We are currently investigating the issue.
Affected components
4Expo in the last 90 days
Full historyIncidents in 90 days
26
Days with an incident
24
Median duration
2 h 34 min
This incident
87% shorter than the median
Other Expo incidents
All incidentsExpo·Elevated submission error rates
This incident has been resolved.
Expo·Elevated iOS submission error rates
This incident has been resolved.
Expo·Elevated API server error rates affecting submissions and builds
This incident has been resolved.
Expo·Website and services partially unavailable due to high database load
This incident has been resolved.
Expo·EAS Update cache issue for rollout updates
This incident has been resolved.
Follow Expo
Your coding agent knows when Expo is down, and tells you when a failure is theirs, not yours. You can also get Expo incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "expo" and tell me if Expo has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=expo/feed subscribe https://outages.cc/feed.xml?providers=expoFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane