5 things Railway’s 8 hour outage should change about how you think about redundancy

Railway runs on Google Cloud, AWS, and its own metal.

So when I first saw that Railway was down for hours, my first thought was probably the same as yours.

"How does a multi cloud platform go dark like that?"

Then I read the incident report, the Hacker News discussion, and the follow up coverage. And the real lesson is uncomfortable.

This was not really a cloud outage.

The servers did not all die. AWS did not die. Railway Metal did not die. Google Cloud infrastructure itself did not have to collapse.

What failed was much higher up the stack.

The account.

Google Cloud placed Railway's production account into suspended status incorrectly as part of an automated action. Railway says this happened around 22:20 UTC on May 19, and the platform was not fully recovered until the next morning. ()

That kind of failure does not look like a server going unhealthy.

It looks like identity, billing, trust, abuse detection, policy, support, and account control all becoming part of your availability story.

Your health checks can say everything is fine.

Your multi zone architecture can be green.

Your workloads can still technically exist.

But if the account is restricted, your beautiful infrastructure diagram does not matter much.

This is the part many teams do not model.

They model "what if eu west 1 is down?"

They rarely model "what if our production cloud account is frozen by an automated system at 11 PM?"

And honestly, that second one is scarier.

Because you do not debug it with kubectl.

You debug it with support tickets, escalation paths, account managers, legal trust, and luck.

2. The control plane was the real single point of failure

Railway had workloads on AWS and Railway Metal that were still running during the incident. But users still saw errors.

Why?

Because the routing control plane was hosted on Google Cloud.

Railway's edge proxies needed that control plane to know where workloads lived. They had cached route data for a while, but once the cache expired, the edge could not keep routing properly. Railway's community update said route cache expiry caused the incident to spread beyond GCP hosted workloads and affect the wider platform. ()

This is the part people underestimate.

A provider can say, “access restored.”

But your system still has to wake up.

Disks need to attach.

Networks need to behave.

Queues need to drain.

Deployments need to stop stampeding.

Databases need to agree again.

Caches need to be repopulated.

Humans need to verify what is safe.

That is not instant.

And in a complex platform, bringing things back too fast can be worse than bringing them back slowly.

Railway also throttled queued deploys during recovery, which sounds boring, but it is actually the responsible move. Because after an outage, your own backlog becomes traffic. And that traffic can flatten the recovering system.

So the real RTO is not:

"How fast can the provider undo the mistake?"

It is:

"How fast can we safely restore the whole chain after the provider undo the mistake?"

Small difference in words.

Huge difference in reality.

4. Recovery can create a second outage

This is probably my favorite lesson from the whole incident, because it is so real.

When Railway started recovering, queued retries and user activity came back in a burst. That burst hit GitHub OAuth and webhook flows hard enough that GitHub rate limited Railway. So logins and builds had problems again, even after the original Google Cloud issue was no longer the main blocker. ()

So no, account level and provider control plane risk is not some imaginary edge case.

It happens.

But most companies still talk about redundancy like this:

"We use multiple clouds."

Ok, but what does that mean?

Does it mean workloads can run somewhere else?

Or does it mean you can actually operate the business if one provider account disappears?

Those are very different things.

Flexera's 2026 State of the Cloud report shows multi cloud is still a major enterprise pattern, and its report is based on 753 cloud decision makers. (https://info.flexera.com/CM-REPORT-State-of-the-Cloud?lead_source=Organic+Search) But in practice, many companies are multi cloud for procurement, politics, analytics, or workload placement.

Not always for true survivability.

True survivability asks much harder questions.

Can we deploy without this provider?

Can we route without this provider?

Can we authenticate without this provider?

Can we restore backups without this provider?

Can we contact support fast enough?

Can we prove ownership if an automated trust system flags us?

Can we keep serving read only traffic if the control plane dies?

Can we rebuild from another account, another org, or another provider?

That is not as sexy as "active active multi cloud."

But it is probably more useful.

The real takeaway

Railway did have redundancy.

Just not for the layer that failed.

And that is the uncomfortable lesson for the rest of us.

Redundancy at the compute layer does not protect you from account suspension.

Multi region databases do not protect you from provider level identity actions.

Healthy servers do not help when routing control planes cannot tell traffic where to go.

And getting your cloud account back does not mean your service is back.

The next resilience review should not only ask:

"What happens if a region dies?"

It should also ask:

"What happens if our cloud provider suspends our production account by mistake tonight?"