TL;DR Railway published four incident reports in five months covering four unrelated failure domains: its own abuse automation, its CDN, a shared control-plane dependency, and its networking and storage layers.
In May, applications running on Railway Metal and AWS became unreachable for hours while the containers themselves stayed healthy.
No action on the customer side would have restored service.
Below $5,000/month in spend, there is no contractual response time.
Free and Hobby tiers receive a public forum with no guaranteed reply; Pro receives a private thread, typically within 72 hours, with Railway's own documentation explicitly disclaiming any SLO.
The only hard spending cap Railway offers works by taking your workloads offline.
If you run anything revenue-critical on Railway, this article scopes what leaving involves and what to do this week regardless of whether you leave.
It is a smaller project than most teams assume.
Railway made cloud deployment feel straightforward.
Point it at a repository, add environment variables, provision a database, and you have a live URL in minutes without touching a VPC or writing reverse proxy configuration.
For prototypes and internal tools, that remains a highly efficient developer experience.
The calculation changes when the application becomes a business.
Once customers, transactions, production data, background jobs, and revenue run through the platform, deployment speed stops being the metric that matters.
What matters is what happens on the worst day.
Can you see the failure?
Can you act on it?
Will anyone at the vendor respond?
Railway does not publish churn data, and no one can credibly claim a customer exodus.
But you do not need churn data to evaluate this.
The primary evidence is Railway's own incident reports.
They are detailed, candid, and public.
Read end to end, they describe a platform whose failure modes most customers cannot see and cannot mitigate.
A contractual escalation path does exist, but it starts at $5,000 a month in spend, which makes it irrelevant to almost every team writing the migration stories below.
That is the case this article makes.
The migration stories that follow are corroboration, not proof.
Four Unrelated Failures in Five Months One outage is a bad week.
Four failures in four unrelated parts of the stack is a pattern, and it changes what you can plan for.
You are no longer hardening against a known weakness; you are waiting to discover which layer fails next.
Date What happened Confirmed impact What it tells you Feb 11, 2026 An automated abuse-enforcement rule misclassified legitimate services during a staged rollout Under 3% of the fleet received SIGTERM signals, including Postgres and MySQL services; the dashboard kept showing terminated workloads as active Railway's own automation took customers down, and the console displayed the wrong status while it happened, so your monitoring indicated everything was fine Mar 30, 2026 A CDN configuration change enabled caching on domains that had it explicitly disabled ~0.05% of domains for 52 minutes; GET responses without an explicit header could be served to a different user than the one they were generated for A single config push at the edge can turn your application into a data-handling incident, and the only defense was something most teams do not implement by default: setting explicit cache headers on every authenticated route May 19-20, 2026 Google Cloud incorrectly suspended Railway's production account Multiple hours.
API, dashboard, control plane, builds, deploys, and databases down; once cached routes expired, workloads on Railway Metal and AWS returned 404s despite still running Your compute being healthy is not the same as your compute being reachable, and reachability is not yours to control July 2, 2026 Upstream ISP degradation, then a carrier disconnection that removed the last default route at a US East availability zone ~20 minutes with no stable route to the internet, then storage pinned at a third of capacity and roughly 20,000 private-network links blackholed Restoring the network did not restore what depended on it; storage reported healthy while two-thirds of servers in the zone sat waiting on disk May Is the One That Should Change Your Risk Model Railway runs workloads across Railway Metal, AWS, and GCP, connected by redundant interconnects.
Its edge proxies populate their routing tables from a network control plane API hosted inside Google Cloud.
When GCP suspended the account, the mesh held for about an hour on cached routes.
Then the caches expired, the edge could no longer resolve routes to running instances, and applications on Metal and AWS began returning 404s.
The containers never stopped.
Customers simply could not reach them.
Consider what that means operationally: There was no failover you could trigger No region you could shift to No configuration on your side that would have helped No dashboard to work from, because the dashboard was down too Core services were not confirmed operational again until roughly 04:00 UTC, nearly six hours in.
Railway did not move the incident to monitoring until 06:14.
For most of that window, the correct action for every Railway customer was to wait.
Railway took responsibility for the architecture and is removing the dependency.
It does not change the exposure you were carrying without knowing it.
July Shows the Same Shape at Smaller Scale A carrier degradation is routine internet weather, and multi-carrier routing handled it correctly.
The damage came afterward: a disconnection made without checking which carrier supplied the site's default route, followed by systems that grabbed a bad path during the instability and never re-asserted the correct state once routing recovered.
What makes this dangerous is that everything appeared fine.
Routing tables were correct.
The storage cluster reported a healthy state.
Throughput sat at a third of capacity for nearly two hours until someone found stale connections pinned to a slow management network.
If your own monitoring showed elevated latency that morning, nothing available to you would have explained why.
Teams Leaving or Actively Evaluating an Exit Railway users are not converging on one replacement because they are not solving the same problem.
Some want managed hosting without the incident history.
Some want a conventional cloud, chosen deliberately.
Some are moving down a layer and taking direct ownership of the server and deployment stack.
Some end up on another platform with no notice at all.
Customer or workload Destination Trigger Evidence type FeedAI DigitalOcean App Platform Latency spikes, incomplete requests, unresponsive endpoints First-person founder account SoundBoost.ai Hetzner dedicated server May outage, unexplained lag spikes, latency, and cost first-person account, X post Every Render Random failures, downtime, unclear communication as AI prototypes became customer-facing products customer interview published by the destination vendor FastAPI expense-tracker app AWS EC2 and RDS Production control, networking visibility, direct database ownership first-person LinkedIn account post SmartFolio Coolify on self-hosted VPS Own the stack; platform limits throttling traffic spikes; lower cost first-person account, LinkedIn post B2B enterprise app Microsoft Azure Emergency migration during the May 19 outage itself, not a planned exit first-person account, posted live (Hacker News) Growing n8n implementation Under evaluation 40+ workflows, concurrency, chained webhooks, long-running executions First-person account describing migration intent FeedAI → DigitalOcean Incomplete requests and intermittently unresponsive endpoints.
The team audited its own application first, concluded the hosting environment was contributing, and moved the API to DigitalOcean App Platform.
They report more consistent latency and fewer dropped requests afterward.
The founder suspected hostile traffic but never confirmed it.