Google Cloud Nuked Railway's Production Account for 8 Hours

An automated system broke the platform that hosts automated systems. The irony writes itself.

Railway published its incident report: at 22:20 UTC on May 19, Google Cloud's automated systems incorrectly suspended Railway's production account. Not a single service. The entire account. API gone. Control plane gone. Databases gone. All GCP-hosted compute, gone. The outage lasted until approximately 06:14 UTC on May 20. Eight hours.

The cascading failure is what caught my attention. Railway's architecture used GCP for workload discoverability, which meant that even as cached network routes kept some services partially alive, they degraded as caches expired. There was no fallback discovery mechanism. When GCP said "this account doesn't exist anymore," every dependent system eventually agreed.

This hit 486 points on Hacker News, and the discussion was brutal. The core question: how does a cloud provider's billing automation become a single point of failure for a platform hosting thousands of production workloads?

The answer is uncomfortably simple. Account-level suspension is a nuclear option that cloud providers treat as routine. It's automated. It fires on heuristics. And it kills everything. Not a VM. Not a project. Everything. Railway's technical architecture didn't matter. Their redundancy didn't matter. Their monitoring didn't matter. A billing algorithm decided their account was suspicious, and eight hours later someone at Google manually un-suspended it.

For builders: this is your reminder to audit account-level dependencies. Most of us think about service redundancy, region failover, and multi-AZ deployments. Almost nobody plans for "my cloud provider deletes my account." But it happens. Google has done this before. AWS has done it. If your entire stack is in one cloud account, your blast radius is that entire stack. Period.

The practical move: keep your domain registrar, DNS, and status page on a separate provider and a separate account. Build a static fallback page that can go live when your primary infrastructure is unreachable. And if you're running a platform, consider a multi-cloud discovery layer that doesn't depend on any single provider's goodwill.