In May, Google Cloud suspended Railway’s production account with no warning. Within minutes, the platform was down everywhere, including the workloads Railway ran on Amazon Web Services and on its own bare-metal hardware.
The outage lasted around eight hours, because Railway’s edge proxies depended on a GCP-hosted control plane to populate their routing tables, and as the cached routes expired, every workload started returning errors regardless of where it physically ran. The AWS and bare-metal infrastructure hadn’t failed at all. The platform had simply become unreachable, cut off by a dependency nobody had drawn on the diagram.
Railway had done exactly what resilience advice tells you to do, spreading workloads across more than one provider. But it made no difference, because the coupling that took everything offline sat below the layer the redundancy was protecting. What failed was a single account-level relationship with one provider, sitting underneath the whole estate – it had never appeared in anyone’s picture of how the system was configured.
The headline reads “cloud outage”, which pulls the conversation towards provider reliability. That conversation is fair enough, but it misses the structural point: the dependency that cascades is almost never the one the resilience budget was spent on.
Redundancy protects the failure you can see
Most resilience investment goes into the visible failure surface. Teams build across multiple availability zones, then across multiple regions, because those are the failures that have names and post-mortems and architecture-diagram boxes.
Distributing services across regions with independent failover is the right instinct and I’ve argued for it before, but geographic distribution is necessary without being sufficient, because the coupling that brings a platform down is usually not geographic at all. It’s a control plane every region calls home to, an authentication provider sitting in front of everything, an account boundary with one upstream vendor underneath the whole estate. The common thread is that none of them are being tracked as part of the system’s configuration.
GitHub spent the early part of this year demonstrating what that looks like at scale. CTO Vlad Fedorov attributed the February and March outages to rapid load growth combined with architectural coupling that let localised problems cascade across critical services, and the root cause analyses of the worst incidents found single points of failure underneath systems that were supposed to be independent. GitHub Actions was the most-affected service, with dozens of outages across the year, and the disruptions were still landing into June.
The cause everyone pointed to was a half-finished migration, with only around 12.5% of traffic served from Azure as of March. Another way to describe a half-finished migration is an estate running in two configurations at once, where production and the partially-migrated environment have drifted out of step with each other, and the seams between them are the part no test exercised because no single baseline described the whole thing.
That drift is the real exposure, and it builds up in normal operation, not just during migrations. Systems move away from the state they were tested in one undocumented change at a time, a firewall rule added under pressure, a service that now authenticates somewhere it didn’t a year ago. None of it is logged as a resilience decision because none of it felt like one. The coupling that cascades is the accumulated total of those changes, and an organisation that can’t see its current configuration can’t see the coupling either.
GitHub’s stated answer is to move more traffic onto Azure and then build toward multi-cloud for longer-term resilience. That solves for capacity rather than for visibility, because a service spread across two clouds still falls over if the shared dependency between them is the part that fails, and spreading across more providers without tracking what each one is doing only adds more configuration nobody is watching.
You can’t manage the configuration you can’t see
Resilience drills mostly test the failures you already know about. You fail over a region precisely because you’ve already named that region as a risk. What they can’t test is the coupling that never made it into anyone’s model of the system, and running the drill again won’t close that gap. It closes only by knowing what your estate is actually configured to do right now, across every layer, including the provider relationships and control-plane dependencies that never show up in an application diagram.
That means watching the boundaries dependency reviews usually stop at, the places where your estate hands control to something you don’t operate. During the Railway outage, users couldn’t reach their own database backups because the dashboard and API they’d have used to retrieve them were down in the same event.
I made the case after October 2025 that recovery tooling should stay independent of the systems it’s meant to recover, and the Railway cascade is the version of that I hadn’t fully accounted for, because a recovery plan that authenticates through the same provider that just failed isn’t a recovery plan at all.
Continuous configuration visibility is unglamorous compared to a failover architecture, but it’s the thing that surfaces the coupling, because it tracks what every part of the estate is set to do and flags when something has moved from where it was. This is the ground on which the latest configuration monitoring software is built on: these tools can scan the whole estate, from servers and network infrastructure to cloud platforms and the logical layers in between, hold a baseline of how each piece is configured, and show you when something has drifted from it.
Railway is now redesigning so that no single provider account sits in the hot path of everything else. The organisations that can already see that kind of dependency in their own estate are the ones who get to make that change on a planning timeline, rather than discovering it during the eight hours the platform is down. This is only possible by establishing continuous configuration visibility across the IT estate.
