Google Cloud / Railway / incident
Updated 23 Sep 2026

One suspended account cut off three clouds

How an automated Google Cloud suspension of Railway's production account in May 2026 also made workloads on AWS and Railway's own hardware unreachable.

Scope / All Railway regions and providers; roughly 8 hours to monitoring

Multi-cloud is one cloud if the control plane lives in one account.

What happened

At 22:10 UTC on 19 May 2026, Railway’s monitoring detected failing API health checks. By 22:19 UTC, the company had identified the cause: Google Cloud had suspended its production account as part of an automated action. Railway said Google had sent earlier violation notices, but no notice before this suspension.

Account access returned at 22:29 UTC, but compute instances stayed stopped. Railway’s edge proxies held a cache of routing tables from a network control plane that ran inside Google Cloud. Once that cache expired at about 22:35 UTC, workloads on AWS and on Railway Metal were still running but unreachable. The edge could no longer resolve routes to them.

Networking recovered at 01:38 UTC. The API and dashboard were operational by 04:00 UTC, and the incident moved to monitoring at 06:14 UTC on 20 May.

The boundary

This is Railway’s account of the incident. Google has not published its own explanation, and the details of the underlying terms-of-service finding are not public. Railway runs capacity on three providers, and the non-Google hardware did not fail. It became unreachable through a shared dependency.

Railway committed to removing the Google-hosted control plane from route discovery, spreading database shards across AWS and Metal, and keeping Google Cloud out of the data plane’s critical path.

The point

Count a provider as independent only after its workloads are proven to keep serving when any single account, including the one hosting your control plane, is switched off.

Sources

More incident dossiers

All cloud outage evidence → · Test your cloud exit readiness →