Is Expo Down Right Now? Check if there is a current outage ongoing.

We are continuing to investigate this issue. Still looking like a GCP outage.

We are continuing to investigate this issue.

We are currently investigating. Looks to be a possible GCP outage.

We are seeing failures when installing Pods. It is caused by underlying failure to download prebuilt Hermes library, in which case Pods try to set up building Hermes from source which may fail.

We are seeing failures when installing Pods. It is caused by underlying failure to download prebuilt Hermes library, in which case Pods try to set up building Hermes from source which may fail.

We are currently investigating this issue.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

We have identified the issue and are fixing it.

We are currently investigating this issue.

We are currently investigating this issue.

Looks like things are back to normal!

The issue seems to be caused be intermittent GCP errors, but we'll keep an eye on it.

The issue seems to be caused be intermittent GCP errors, but we'll keep an eye on it.

This incident has been resolved.

Since 8 PM UTC check run statuses of GitHub Builds are not being updated. We have identified the issue and a fix is being deployed.

Since 8 PM UTC check run statuses of GitHub Builds are not being updated. We have identified the issue and a fix is being deployed.

Starting at 6 a.m. PDT, App Store Connect will be unavailable for up to two hours. Please make any critical iOS deliveries or changes before this time.

Scheduled maintenance is currently in progress. We will provide updates as necessary.

This incident has been resolved.

While a fix is being deployed, the error rates have come down to the usual levels on their own. We will keep an eye on the situation.

As we're fixing the situation you may see slightly increased wait times for EAS Build.

We are currently investigating this issue.

We are currently investigating this issue.

Between April 3rd, 8 PM and 10 PM UTC we have seen an increased number of iOS submissions failures. They seem to have been caused by an Apple servers outage (we were getting "Internal server error" HTTP responses when not expected). [Application Loader Error Output]: [ContentDelivery.Uploader.6000039FC140] RETRIEVE UPLOAD OPERATIONS (UPLOADING ASSET DESCRIPTION): received status code 500; internal server error. (500)

Between April 3rd, 8 PM and 10 PM UTC we have seen an increased number of iOS submissions failures. They seem to have been caused by an Apple servers outage (we were getting "Internal server error" HTTP responses when not expected).[Application Loader Error Output]: [ContentDelivery.Uploader.6000039FC140] RETRIEVE UPLOAD OPERATIONS (UPLOADING ASSET DESCRIPTION): received status code 500; internal server error. (500)

Between 5 AM and 10 AM UTC our NPM caches have been intermittently dropping network connections when installing packages which caused a percentage of jobs to fail. All builds affected by this should have gotten automatically waived (we don't charge for those). Sorry for the trouble!

Between 5 AM and 10 AM UTC our NPM caches have been intermittently dropping network connections when installing packages which caused a percentage of jobs to fail. All builds affected by this should have gotten automatically waived (we don't charge for those). Sorry for the trouble!

This incident has been resolved.

NPM is experiencing "intermittent issue with installing packages" which is causing EAS Jobs to fail. They have already implemented a fix and we see a lower rate of errors now, but we'll keep monitoring the issue.

NPM is experiencing "intermittent issue with installing packages" which is causing EAS Jobs to fail. They have already implemented a fix and we see a lower rate of errors now, but we'll keep monitoring the issue.

This incident has been resolved.

The situation has improved. Last error like this happened 5 minutes ago, while previously they were happening at a rate of 2 errors / minute. We'll keep monitoring the situation.

Looks like an upstream issue with Google KMS is causing some operations on iOS Builds to fail (and thus fail the Builds).

This incident has been resolved.

The situation has improved. Last error like this happened 5 minutes ago, while previously they were happening at a rate of 2 errors / minute. We'll keep monitoring the situation.

Looks like an upstream issue with Google KMS is causing some operations on iOS Builds to fail (and thus fail the Builds).

Between 3:44 a.m. PST and 8:08 a.m. PST some users were not able to access build details page in the EAS Dashboard. The issue has been resolved and fix has been applied.

Between 3:44 a.m. PST and 8:08 a.m. PST some users were not able to access build details page in the EAS Dashboard. The issue has been resolved and fix has been applied.

For around an hour between 8 a.m. PST and 9 a.m. PST some users were not able to access parts of EAS Dashboard. The situation was resolved at 9:07 a. m. PST. We are investigating the root cause.

For around an hour between 8 a.m. PST and 9 a.m. PST some users were not able to access parts of EAS Dashboard. The situation was resolved at 9:07 a. m. PST. We are investigating the root cause.

We're experienced an elevated level of API errors and partially reduced availability. The issues have been addressed, and everything should be back to the operational state.

We're experienced an elevated level of API errors and partially reduced availability. The issues have been addressed, and everything should be back to the operational state.

The scheduled maintenance is done and all affected services have been restored.

Scheduled maintenance is currently in progress. We will provide updates as necessary.

We will be performing database maintenance during off-peak hours. We expect the maintenance to take 10 to 15 minutes. During this time, old apps that check for classic updates will receive a response saying there is no update and they will launch with the latest update they already have and minimal impact to end users Older Snacks using SDK 49 and older will also be offline. After the maintenance period, all services will be restored to normal.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

We are currently investigating this issue.

At around 7 a.m. PST, our API servers experienced a widespread internal error, causing downtime for many of the services and tools that depend on them (expo.dev website, EAS CLI, etc.).This issue was resolved at 7:11 a.m. PST. We are investigating the root cause.

Users reported issues loading particular views on the website (expo.dev) due to errors from stale cache items causing requests to non-existent resources. We have addressed the problem, and users should now be able to load the website as expected.

This incident has been resolved.

We are continuing to monitor for any further issues.

The underlying issue was resolved. We are monitoring queue times.

A fix has been implemented and we are monitoring the results.

We are continuing to investigate this issue.

We are continuing to investigate this issue.

We are currently investigating the issue causing increased queue times for Android builds

This incident has been resolved. Please update to the latest EAS CLI version 15.0.12

Creating new Apple Push Notification keys is currently failing due to recent changes in Apple’s API. The root cause has been identified and a fix is in progress. As a workaround, you can generate the push key manually in the Apple Developer portal and upload it to EAS.

This caused many builds to fail during the incident period as a result of failed network requests, such as during Node package installation and CocoaPods installation, or cloning the VM image. All builds that failed between 11:09AM and 12:50PM were waived and will not count against usage.

The issue was related to the removal of artifacts for the BlurView package from Jetpack (https://github.com/jitpack/jitpack.io/issues/6766#issuecomment-2591888851). The PR with the fix bumping the version of this dependency was already merged (https://github.com/expo/expo/pull/34012).

We are aware of ongoing issues with JitPack services (https://status.jitpack.io/) that may affect Android builds. These upstream issues could lead to build failures or delays. Our team is monitoring the situation closely and will provide updates as we learn more.

We reenabled the Maven cache to overcome the rate-limiting issue and success/error rates for Android builds are back to normal.

Some Android builds started to fail with the 429 error code during the "Run Gradle" build phase. We are working towards mitigating this issue.

Some libraries, like expo-blur and expo-camera, depend on a library that is hosted on JitPack, which is currently experiencing an outage. If you are using one of these libraries in your project, your build may fail on Android.

We observed a higher than average database load due to a SQL migration that caused other database queries to fail. The issue was identified, a fix was implemented and all services are once again responsive.

A fix has been implemented and we are monitoring the results.

We are currently investigating this issue.

Between 02:00 and 02:21 PST we observed a higher than average database load due to a migration. The issue was identified, a fix was implemented and all services are once again responsive.

We have implemented a fix for the database, and all services are responsive. We will follow-up with other fixes to maintain the stability.

The issue has been identified and a fix is being implemented.

We are continuing to investigate this issue.

We are observing a higher-than-average database load that is causing availability issues for our APIs. Unfortunately, this is causing an extremely high latency, which results in unresponsive services on the website and our CLI tooling. We are investigating the cause and are working on a fix.

We are observing a higher-than-average database load that is causing availability issues for our APIs. This affects using our website, as well as submitting and processing builds and submissions.

This incident has been resolved.

We've added failing 3rd party repository to our internal Maven proxy cache. Things should be getting back to normal.

We're working on bringing back Android builds. We'll waive charges for failed Android builds for the period of the outage. Sorry for the inconvenience.

The Apple authentication fix in the latest eas-cli version (12.5.4) has been confirmed by multiple external people. If you are running into this issue, upgrade your eas-cli version - or open a new issue report on https://github.com/expo/eas-cli/issues. For the latest information see GitHub: https://github.com/expo/eas-cli/issues/2639

Upgrade to `eas-cli@12.5.4`, which contains a fix for the Apple authentication issue. We will monitor the rollout until we are confident the issue is resolved.

The issue has been identified and a fix is being implemented.

Public Apple Developer authentication API has changed, impacting automation tools like EAS CLI. We are currently investigating the issue. You can work around it by running builds with the `--non-interactive` flag, in order to skip authenticating and re-use existing app signing credentials. Follow along with updates on GitHub: https://github.com/expo/eas-cli/issues/2639

This incident has been resolved.

You may get an error message when attempting to install Node 20.15.1 and 22.4.1 like this: Version '20.15.1' not found - try `nvm ls-remote` to browse available versions. Failed to install Node.js v20.15.1 We are working on this and as a temporary workaround, please use the prior release of Node: 20.15.0 or 22.4.0.

The faulty deployment introduced a bug that caused build artifacts to not be uploaded correctly to storage buckets. Developers trying to download the artifacts of affected builds could see an error like "The specified key does not exist. No such object: ..." The issue also affected submissions trying to upload the builds with broken artifacts. The developers who encountered the issue saw an error like "Failed to download the archive file (Response code: 404 Not Found)" The issue was identified by the Expo team and the deployment was reverted at around 10 AM GMT. The charges for all of the broken builds were waived.

This incident has been resolved.

We're experiencing an elevated level of build errors and are currently looking into the issue. It appears to be caused by a partial GCP outage. We're monitoring the issue.

This incident has been resolved.

We're experiencing an elevated level of builds errors and are currently looking into the issue. It appears to be caused by a partial GCP outage. We're monitoring the issue.

Once again this seems to be resolved for good. Third time’s a charm!

We're yet again experiencing an elevated level of builds errors and are currently looking into the issue. The underlying issue remains to be a partial GCP outage. We're monitoring the issue.

The errors are no longer happening. Happy Sunday!

We're experiencing an elevated level of builds errors and are currently looking into the issue. It appears to be caused by a partial GCP outage. We're monitoring the issue.

All is good. Keep on building!

Errors have stopped, we're hopeful for good. We'll keep an eye on it for a bit.

We're experiencing an elevated level of builds errors and are currently looking into the issue. It appears to be caused by a partial GCP outage. We're monitoring the issue.

This incident has been resolved.

The issue seems to be fixed on the GCP side, the error metrics are recovering

We're experiencing elevated levels of Android builds errors. The issue seems to be caused by an underlying GCP outage: https://status.cloud.google.com.

This incident has been resolved.

We're experiencing an elevated level of App Store Connect upload timeouts and are currently looking into the issue.

The incident is resolved on the GCP end and error rates look healthy again.

We are investigating the issue causing Android builds to fail when starting a new Linux VM. Looking at the error messages this issue seems to be caused by some outage on the GCP side.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

Developers can not load their GitHub information on the Expo website or execute GitHub builds. We are investigating now.

A faulty EAS Build deployment broke the "Configure expo-updates" build phase for most developers. The deployment was reverted, and therefore the issue was fixed. We've waived all failed builds between 15:43 GMT and 17:09 GMT.

Expo Go code signing works by using the following mechanism: [https://github.com/expo/code-signing-certificates/pull/1](https://github.com/expo/code-signing-certificates/pull/1) - Expo Go root certificate embedded in the Expo Go application. Valid for 40 years. Private key kept offline. - Expo Go intermediate certificate downloaded by `@expo/cli`. Valid for 2 years. Private key kept on signing server. This is a child certificate of the Expo Go root certificate. - Expo Go development certificate generated and downloaded by `@expo/cli`. When a project is started \(`npx expo start`\) we sign the project manifest to ensure scoped module impersonation isn’t possible within Expo Go \(accessing scoped modules for other projects run in Expo Go\). To do this signing, a private key and certificate signing request is generated. This CSR is sent to the expo signing server, and a development certificate valid for 30 days is returned. This development certificate is a child of the Expo Go intermediate certificate. Then, when Expo Go loads an app, it checks that this certificate chain is valid \(all certificates are valid and lineage is correct\). The incident here was that, while we had planned to refresh the Expo Go intermediate certificate every year to preempt the 2 year validity expiration, it was overlooked. So the Expo Go intermediate certificate expired and therefore the certificate chain was invalid. Note that this only affected projects in local development. The fix was to re-generate a new Expo Go intermediate certificate from our root certificate \([https://github.com/expo/code-signing-certificates/pull/14](https://github.com/expo/code-signing-certificates/pull/14)\) and then update the certificates on the signing server. After the signing server updates were deployed to production, all future requests for a development signing certificate now use the new intermediate certificate. Users still seeing issues should ensure they are not using the `--offline` flag \(at least once\) when running `npx expo start` to get a new development certificate with the updated intermediate certificate.

This incident has been resolved.

Certificate rotation complete. Re-running `npx expo start` (no `--offline` flag) should refresh the certificate for local development of projects.

Certificate has been rotated/updated and is being deployed.

Users are unable to load their projects in Expo Go at the moment. We are investigating it now. As a workaround, you can create a development build to resume developing your application: https://docs.expo.dev/develop/development-builds/introduction/ We appreciate your patience as we try to get a fix out ASAP!

The service was back online with security improvements as of 5:11PM PST

EAS Submit for iOS is temporarily unavailable while performing security-related maintenance

Snack uses a few services to make it work, and a couple of them became completely unavailable for about half an hour. The cause was that we upgraded our main cluster to use faster servers but some of the services were labeled as being compatible only with the older servers and didn’t have any hardware to run on. In practice, all of our services are compatible with the newer servers and fixing the compatibility labels brought the unavailable services back.

This incident has been resolved.

Snack is up and running again. We're monitoring our charts to make sure everything stays healthy.

One of the infrastructure components of Snack is currently down. We are actively investigating the cause and have identified the problem and are working to resume its availability.

This incident has been resolved.

We are currently experiencing a networking issue with our iOS cluster provider causing iOS builds and submissions to fail.

This incident has been resolved.

We are continuing to monitor for any further issues.

A fix has been implemented and we are monitoring the results.

We are currently investigating the issue. Android builds seem unaffected.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are investigating the networking issue causing iOS EAS Build builds to fail.

All services are back to normal.

We have implemented a fix and are actively monitoring the services.

We are observing a higher than average server load that is causing availability issues for our APIs. This affects using our website, as well as submitting and processing builds and submissions.

The Apple status page reports that the outage has been resolved as of 3:20PM PDT. We have confirmed that iOS submissions are successful and the issue is resolved.

An upstream incident with App Store Connect uploads is causing iOS apps submitted with EAS Submit to sometimes not appear in TestFlight, or appear with a significant delay. For more details, see https://developer.apple.com/system-status/

Erroring endpoints have been at nominal perfomance for the past 30 minutes. Observed errors were caused by misconfiguration related to ongoing security improvements.

Beginning at 1:01 PDT, build and update endpoints have had elevated error rates. A potential cause has been identified and fixes deployed.

This incident has been resolved.

The EAS Build job scheduling programs have been restarted as of 12:00PM PT and we have successfully created builds for both Android and iOS. The infrastructure is healthy, too, according to our charts. We will keep monitoring the heath of EAS Build and believe the issue to have been resolved.

We are investigating an issue with EAS Build that causes new build submissions across both platforms to fail with a 'build command failed' error in the EAS CLI. These failed build submissions do not count against your build credits.

All API services were briefly unavailable for a few minutes during a database restart. All services are now back online and working normally.

This incident has been resolved.

Devices that are attempting to newly register for push notifications will not be able to do so. Sending push notifications is still active.

The cloud provider we use for our database and cache infrastructure will be performing scheduled maintenance (patch upgrades) at 3PM and 4PM PT today. We expect the downtime to be a couple of minutes.

This incident has been resolved.

Server availability is recovering after a database component was restarted. A very large number of database queries had created contention. Database and server health are now looking like normal and we will monitor them until the incident is resolved.

The API server that EAS CLI and the website use is partly unavailable. We are investigating the issue.