Dora NodaOn January 22, 2026, Railway announced a $100M Series B to build what it calls an "AI-Native Cloud." Four months later, on May 19, 2026, Google Cloud suspended Railway's production account without warning, and the entire platform — API, dashboard, control plane, every customer's database — went dark for roughly eight hours. It was the fourth publicly documented major incident since the previous November, and a fifth followed three weeks later.
Raising money and reliability slipping are not usually the same story. But for a team currently running production traffic on Railway, or evaluating it against Render, Fly.io, or a self-hosted alternative, the incident count is only the headline. The number that actually matters is what one of these outages costs your team, in dollars, the next time it happens — and what Railway is contractually on the hook to give back when it does.
The Five Incidents, Graded Honestly
Not every item on this list deserves the word "major." Grading them by actual blast radius, from Railway's own published postmortems:
| Date | Incident | Duration | Severity | What broke |
|---|---|---|---|---|
| Nov 20, 2025 | GitHub webhook surge overwhelmed the deploy queue | ~2 hours | Moderate | New deploys stalled fleet-wide; already-running services stayed up |
| Dec 16, 2025 | Next.js RCE (CVE-2025-55182) let attackers deploy a cryptominer on customer workloads | ~4 hours | Major | Fleet-wide CPU starvation from the miner load; <10% of workloads degraded, EU West hit hardest; private networking dropped <1% of traffic |
| Feb 18–21, 2026 | Nine DDoS waves plus an unrelated Cloudflare BGP route withdrawal | 30 sec–48 min per customer, across 4 days | Moderate | Intermittent, short per-customer impact windows rather than one continuous outage |
| May 19–20, 2026 | Google Cloud suspended Railway's GCP account | ~8 hours | Major | Platform-wide: API, dashboard, control plane, and every GCP-hosted database offline |
| Jun 11, 2026 | "Deployments may be slow to go out" | Minor, undisclosed duration | Minor | Deploy latency only |
So the honest count is three incidents serious enough to call major (Dec 16, May 19, and arguably Feb 18–21 by cumulative days-long duration even though no single window was long), one moderate deploy-queue stall, and one genuinely minor slowdown. Bundling all five under "major outages" inflates the headline — but three unrelated major-or-near-major incidents in seven months, on a platform whose entire value proposition is "you don't have to think about the infrastructure layer," is still the story.
The May 19 incident is the one worth dwelling on, because it's structurally different from the other four. It wasn't a bug in Railway's code, a supply-chain attack, or a traffic spike — it was Google Cloud, unilaterally and without proactive notice, cutting off Railway's ability to run anything. Every customer running on Railway inherited a business dispute between Railway and its own upstream vendor. That's the failure mode a platform team can't patch around, because it isn't Railway's failure to fix — it's a dependency they don't control, passed straight through to you.
What Railway Owes You When It Goes Down
Here's the part migrating teams usually assume and don't check: Railway's public plans — Hobby ($5/mo) and Pro ($20/mo per seat) — carry no published SLA or service-credit policy. The uptime history lives on a public status page with postmortems, which is transparency, not compensation. Only Enterprise customers get contracted SLOs, and those terms aren't published — they're negotiated per account.
Practically: if you're a team on Railway Pro or Team plans (the tiers almost every migrating startup lands on), an 8-hour platform-wide outage entitles you to nothing beyond an apology blog post. Whatever the outage costs you, you eat the entire bill yourself. That's not unusual among usage-metered PaaS vendors — but it means the SLA-credit line item in any "what does downtime cost us" spreadsheet is, for most Railway customers, simply zero.
The Actual Incident Math for a Mid-Size Team
Skip the industry-wide "average cost of downtime" stats — the oft-cited Gartner figure of roughly $5,600/minute is calculated from large enterprises with call centers and trading desks, and it will make any indie SaaS's numbers look absurd by comparison. What actually lands on a 5-to-15-person team looks more like this, and it varies along two axes that matter: how long you're down, and how much revenue moves through the app per hour.
Direct revenue exposure (assuming revenue is roughly linear over the day, which understates real impact — checkout abandonment and lost signups compound faster than a straight proportion):
| Monthly recurring revenue | Per-hour exposure | 2-hour incident (Nov 20-style) | 8-hour incident (May 19-style) |
|---|---|---|---|
| $10,000 MRR | ~$14/hr | ~$28 | ~$111 |
| $30,000 MRR | ~$42/hr | ~$83 | ~$333 |
| $100,000 MRR | ~$139/hr | ~$278 | ~$1,111 |
Direct revenue loss is the smallest line item, and it's the one most postmortem-reading engineers stop at. The bill that actually shows up in the next sprint retro has three more lines:
- Incident-response labor. A platform-wide outage pulls in whoever's on call, plus usually one or two more engineers debugging "is it us or is it them" for the first 30–60 minutes before Railway's status page confirms it's them. For a $30k-MRR team, that's realistically 3 engineers × the incident duration × a $100/hr fully-loaded rate — $600 for a 2-hour incident, $2,400 for an 8-hour one.
- Support and churn buffer. Every incident generates support tickets, and a subset of affected trial users or low-commitment customers simply don't come back. This is the hardest line to price precisely and the one most likely to get hand-waved to zero — don't. Even a conservative 1–2% churn allocation against the affected week's new-signup cohort is real money for any team past its first few customers.
- SLA credit received. $0, per the previous section, unless you're on a negotiated Enterprise contract.
Put together, a $30k-MRR team's realistic bill for the May 19 incident is closer to $2,700–$3,500 once labor and a conservative churn allowance are counted — roughly ten times the $333 the pure-revenue column suggests. That gap, not the headline revenue number, is the actual argument for taking a five-incidents-in-seven-months track record seriously.
The Hot-Standby Tax
The obvious mitigation is to run a warm failover on a second platform — deploy the same app to Fly.io or Render, keep it idling, and flip DNS if Railway goes down. For a team already spending, say, $400/month in Railway usage, standing up an equivalent standby roughly doubles the infrastructure line to $800/month — $4,800/year of pure insurance premium for a handful of incident-hours a year.
And it's an imperfect hedge. A hot standby on another usage-metered PaaS still puts you behind someone else's control plane and someone else's upstream cloud account — it diversifies which vendor's incident can hit you, but it doesn't remove the category of risk. If your standby provider has its own GCP-account or control-plane incident on the same day (not implausible — Cloudflare's February 20 BGP incident affected many downstream customers at once, Railway included), you've paid double and gained nothing.
Whose On-Call Is It Anyway
This is the honest version of the "just self-host" argument, not the oversold one: moving the same workload onto owned Hetzner hardware doesn't make outages disappear. A DDoS wave like February's would still find you; hardware fails; you'll still have bad days. What changes is which failure modes you're exposed to, and who's holding the pager when they happen.
Three of Railway's five incidents — the Nov 20 deploy-queue stall, the Dec 16 cryptominer/CPU-starvation event, and the May 19 GCP suspension — were failures of a shared, multi-tenant control plane that Railway operates and you don't. None of those three categories exist if there's no multi-tenant control plane between your app and your hardware: no other tenant's traffic surge stalls your deploy queue, no other tenant's compromised workload starves your CPU, and no upstream cloud vendor can suspend an account that's yours, not a platform vendor's, to suspend.
The cost side of that trade, at post-June-2026 Hetzner pricing: three AX52 dedicated nodes (control plane plus two workers) run roughly €64/month each, about €192 (~$210) a month — cheaper than the hot-standby tax above, run on hardware under a contract with Hetzner directly rather than a third party's cloud account. What you're buying isn't a lower incident rate; it's an incident your team detects and resolves on its own timeline, instead of one you diagnose by refreshing a vendor's status page and wait on a postmortem to explain three days later.
This is the gap Bex.co is built to close: a Cluster API–managed fleet on machines you own, with a Render-compatible deploy-from-git workflow, so "own the on-call" doesn't mean rebuilding a PaaS's control plane yourself. Push a repo, get a running HTTPS service — on hardware where the only account that can get suspended is one you signed up for directly.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
