Railway's July 2026 US East Outage: What One ISP's Bad Route Cost Every App — and What Owning the Network Costs Instead

At 07:44 UTC on July 2, 2026, apps in Railway's US East region started timing out — not because Railway's compute failed, not because its control plane crashed, but because a single upstream carrier's US backbone degraded and congestion spilled onto the route carrying Railway's inter-region traffic. By the time the incident was resolved at 12:01 UTC, every app in the zone had lived through roughly four hours and seventeen minutes of elevated latency, packet loss, and intermittent unreachability. For about twenty minutes in the middle — 08:39 to 08:59 UTC — the zone had no stable route to the internet at all.

Here is the whole argument of this post in one table, up front:

The point of the comparison is not "Railway bad, bare metal good." Railway's postmortem is genuinely excellent, and owning your network does not make carriers stop failing. The point is the question the outage forces: how many independent points of failure sit between your app and the internet — and how many of them can you name, verify, or change? On a shared multi-tenant platform, the honest answer to all three is usually "none."

Anatomy of the Outage: One Carrier, Five Failure Dominoes​

Railway's incident report is unusually detailed, and the timeline is worth reading closely because almost nothing in it is about compute:

The root-cause chain has five links, and each one is instructive:

1. A carrier's backbone degraded. In Railway's words, "a carrier carrying our traffic was impacted by a network degradation somewhere in their US backbone." Traffic that carrier normally moved on other paths spilled onto the route between Railway's US West and US East, saturating it.
2. The first mitigation worked. Railway disconnected the degraded ISP at all US borders and rerouted. This is exactly what multihoming is for.
3. The second mitigation removed the last exit. Disconnecting a second carrier at 08:39 inadvertently withdrew the zone's last default route. Unlike Railway's newer datacenters, this older US East zone still depended on its carriers to supply the default route — a legacy design detail nobody had reason to look at until it was the only thing that mattered.
4. Storage silently failed over to the wrong network. With the fabric's default route gone, servers fell back to the management network — a path with a small fraction of the fabric's capacity. Worse, connections "keep using the path they started on until they close," so storage stayed stuck on the slow path for nearly two hours after routing was healthy.
5. Private networking learned the wrong addresses and kept them. Address rewriting during the disturbance meant tunnels cached the wrong peer address even after the rollback. Roughly 20,000 host-to-host private network links were blackholed until mesh agents were restarted fleet-wide.

One upstream ISP's bad day, two hidden legacy dependencies, and a multi-tenant blast radius: that is the whole incident. Railway's compute never failed.

Counting Independent Points of Failure​

The question a team should actually ask after reading that postmortem is not "should we leave Railway?" It is: enumerate every independent thing that must work for my app to be reachable, and mark which ones I can see, verify, or change.

On a shared multi-tenant platform, the chain looks like this — with your visibility at each hop in parentheses:

• The platform's upstream carriers and their backbone health (none — you learn the carrier exists from the postmortem)
• The platform's border routing decisions during an incident (none — the 08:39 disconnect happened to you, not with you)
• The platform's default-route architecture, including zone-by-zone legacy differences (none)
• The platform's internal fabric, storage network, and management-network fallback behavior (none)
• The platform's mesh/private-networking layer shared across all tenants (none)
• Your app (yours)

Here is the uncomfortable wrinkle, and it cuts against the naive version of this argument: Railway was not under-provisioned on carriers. The company connects every Metal datacenter to at least three Tier 1 ISPs, explicitly "so that any single carrier can fail without taking us offline." The redundancy existed on paper. It was undermined by a legacy dependency — the old zone leaning on carriers for its default route — that no tenant could have discovered, audited, or tested.

That is the real lesson: redundancy you cannot independently verify or exercise is not your redundancy. It is someone else's, and you find out whether it works at 08:39 UTC on a Wednesday, together with every other tenant in the zone.

On an owned fleet, the same chain is shorter and every hop is inspectable: your provider's (published) carrier mix or your own transit contracts, your routing, your machines, your app. Outages still happen on every one of those hops. The difference is that you can count them, name them, and — critically — drop or diversify any one of them on your own schedule.

What Owning the Network Would Have Cost​

"Own your network path" sounds like a seven-figure infrastructure project. At the scale of teams running apps on Railway, it is not. There are two realistic tiers.

Option A: Rent the redundancy (the 90% case)​

A Hetzner dedicated server — the canonical self-hosted-PaaS substrate — comes with the network diversification already built into the flat price. Hetzner peers at DE-CIX, AMS-IX, DATA-IX, and V-IX, maintains redundant connectivity to multiple national and international carriers, and connects its datacenter parks over redundant dark fiber, so a single fiber or carrier failure does not take a park offline. For all destinations not reachable via peering, traffic rides one of several transit providers.

The price of all of that: it is baked into a ~€37–55/month dedicated server (an AX41-class box with 6 cores and 64 GB RAM comfortably runs a small PaaS fleet's control plane and a handful of tenant apps). You do not get to choose the carriers — but you get a published, inspectable carrier architecture, and if Hetzner's Falkenstein network has a bad week, moving your workload to another provider is a git push, not a platform migration.

Option B: Own the routing (the credible-threat case)​

If you genuinely want the thing the title promises — the ability to disconnect a misbehaving carrier yourself, the way Railway's engineers did at 07:44 — the 2026 price list looks like this:

• ASN registration: $550 one-time from ARIN, or roughly €130/year all-in via a RIPE sponsoring LIR — pocket change.
• IP transit: 2025–2026 market pricing runs $0.05–$3.00 per Mbps per month depending on region, commit size, and provider tier; the most competitive markets held at $0.05/Mbps for 100 GigE commits through Q2 2025. Two independent 1 Gbps commits from different Tier 1/Tier 2 carriers — real multihoming, real BGP failover — costs roughly $100–600/month at typical small-commit rates.
• Colocation: a few rack units with dual power feeds in a carrier-neutral facility, typically $100–300/month.

Total: roughly $300–700/month for a setup where you hold the BGP sessions, you see the carrier degradation in your own graphs, and you decide which session to drop — with no risk that someone else's mitigation removes your last default route, because you know exactly where your default route comes from.

The line item that isn't on the invoice​

Sensitivity check, because the honest version of this comparison does not stop at hardware: the dominant cost of Option B is network operations expertise. BGP multihoming that fails over correctly under pressure is precisely the skill Railway's platform fee buys you — and their postmortem shows even a well-staffed team can trip on a legacy default-route assumption. If nobody on your team can debug a withdrawn route at 3 a.m., Option B's true cost includes a hire or a contract, and Option A (or staying on a managed platform) is the rational choice.

Now weigh it against the other column. Four hours and seventeen minutes of degradation prices out very differently depending on who you are:

• A small SaaS doing $500/hour of revenue: ~$2,100 — annoying, survivable.
• A mid-market company at ITIC's 2025 median of $2,400/minute: ~$616,000.
• ITIC's enterprise cohort, where over 90% of respondents put an hour of downtime above $300,000: $1.3M+ for the window.

At the small end, the outage costs less than a year of Option A. At the mid-market end, it costs more than a century of Option B. Somewhere between those two points is the scale at which "how many independent points of failure sit between my app and the internet" stops being a philosophical question and becomes a budget line.

Owning the Network Doesn't Mean Fewer Outages — It Means Owning the Postmortem​

Here is the counterweight, stated plainly: moving to owned or rented-dedicated infrastructure will not reduce your outage count. Hetzner has upstream carrier incidents. Your own dual-transit colo will have them too. Carriers fail; that is the one constant in this story.

What changes is failure-domain ownership:

• Who detects: your monitoring sees the packet loss on your transit session, not a status page updated after the fact.
• Who decides: dropping a degraded carrier is your call, on your timeline, with your knowledge of your own default routes.
• Who can diversify: adding a third carrier, changing providers, or moving regions is a contract and a config change — not a feature request to a platform.
• Whose postmortem it is: you write it, instead of waiting for it.

Railway deserves real credit here: the postmortem names the mechanism, the mistake, and the fixes (self-generated default routes for older sites, hard guarantees that production traffic never falls back to the management network, alerting on blackholed links). That is what good platform operations looks like. But every one of those fixes is a change to their failure domain that you, the tenant, could neither have requested nor verified — before or after.

So run the checklist from the top of this post against your own stack today: How many carriers sit between your app and the internet? Can you name them? Can you see their health? Could you drop one? If every answer is "I don't know," you have not eliminated those failure points — you have only outsourced the counting.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, where the network path is one you picked and can change. Star the repo on GitHub or deploy your first app today.