Google Cloud blocks Railway account after Unisuper precedent, prompting multicloud warnings

• Multiple posts said Google Cloud suspended Railway's production account without warning, and dexhorthy's outage post described the result as Railway and customer services going down together.
• Gergely Orosz's follow-up said the suspension was automated and hit a customer spending more than $20 million a year on GCP, while zeeg's reply noted there was still no public Google explanation.
• The comparison point surfaced immediately because Gergely Orosz's earlier thread tied Railway to the 2024 UniSuper deletion, and theo's screenshot post pointed readers back to coverage of that incident.
• The practical lesson driving the backlash came from the UniSuper precedent: Gergely Orosz's backup warning said UniSuper avoided full data loss because it had copies outside Google Cloud, matching Google's own UniSuper postmortem and Orosz's earlier writeup.

You can read Orosz's newsletter item, Google's UniSuper incident writeup, and Railway's live status page that customers were linking during the outage. One odd detail in the social fallout was not the outage itself, but how fast the conversation jumped from "what broke" to account-level kill switches and off-cloud recovery paths.

The core claim across the primary posts was not a regional outage or capacity failure. It was an account suspension severe enough to take Railway offline.

Orosz wrote that Google suspended a batch of production accounts automatically, with Railway among them, and added the spending estimate of more than $20 million a year on the platform in his follow-up. dexhorthy's post framed the same event from the customer side, saying Railway and services built on it went down together.

The reason this incident landed so hard is that engineers already had a recent template for it. In 2024, Google Cloud accidentally deleted UniSuper's private cloud subscription, which took services down for roughly two weeks, according to Google's own incident explanation.

That earlier failure is doing most of the interpretive work here. Orosz's thread connected Railway directly to UniSuper within hours, and theo's post amplified an article screenshot reminding people that Google's previous account deletion incident was not hypothetical.

The sharpest concrete point in the reaction was about recovery boundaries, not cloud ideology. Orosz wrote that UniSuper avoided full data loss because it had a backup arrangement outside Google Cloud.

Google's postmortem says the same thing in more formal language: UniSuper maintained data copies in two regions, and one copy sat in a second provider. Orosz's longer Pragmatic Engineer writeup added that Google's internal backups could not restore the deleted subscription on their own, which is why the external copy mattered.

By late May 20, one of the most-circulated follow-ups was still about the absence of public explanation. zeeg's reply asked whether Google had said anything publicly, and Orosz responded that Google should address the incident in public.

That silence matters because the visible claims were specific: automated suspension, no warning, and a large production customer caught in it per Orosz's account. In the evidence here, no Google statement appears to confirm or dispute any of those details.

One concrete downstream impact surfaced outside the core Railway discussion. Nous Research said the Railway outage was affecting Nous Portal users and that it had contacted Railway for an ETA, while linking customers to Railway's status page.

That turns the story from a vendor-account dispute into an application outage visible to end users. Even in this small evidence set, the failure had already escaped the infrastructure layer.