Railway je vývojářská platforma, která vývojářům a firmám po celém světě umožňuje nasazovat aplikace do cloudu bez nutnosti spravovat vlastní servery. Má přes tři miliony uživatelů a patří co do využití cloudu ke střední třídě. Tedy k firmám, které jsou dost velké na to, aby platily opravdu hodně, ale zároveň příliš malé na to, aby byly pro hyperscalery prioritou.
Za provoz své infrastruktury platila Railway Googlu zhruba 46 milionů korun měsíčně (přibližně 2 miliony amerických dolarů). Za celou dobu spolupráce to dělá stovky milionů korun. I přesto se ji Google rozhodl vypnout, aniž by komukoliv řekl jediné slovo.
The Railway dashboard is currently unavailable, and all running Railway services are down.
— Railway (@Railway) May 19, 2026
We're working with our upstream provider to restore service. Updates: https://t.co/DNSc5n1Znj
Co se vlastně stalo
Krátce po půlnoci 20. května (v americkém časovém pásmu šlo o čas 19. května 2026 ve 22:20) Google spustil automatizovaný systém, který pozastavil produkční účet Railway v Google Cloud Platform. Nešlo o cílenou akci vůči Railway, ale o plošný zásah, který postihl více zákazníků najednou. Nikdo z nich nedostal předem žádné upozornění.
Důsledky přišly okamžitě. Zmizelo API, zmizela řídicí vrstva platformy, zmizely databáze i výpočetní infrastruktura provozovaná na Googlu. Uživatelé začali hlásit chybové hlášky „no healthy upstream“ a „unconditional drop overload“, dashboard přestal být dostupný, přihlašování nefungovalo.
Technici Railway identifikovali příčinu za pouhých devět minut a okamžitě podali stížnost Googlu. Ten přístup k účtu obnovil zhruba deset minut poté. Problém byl ale hlubší.
Kaskádový pád
Railway totiž neběží jen na Googlu. Část infrastruktury provozuje na vlastním hardwaru (tzv. Railway Metal) a část na AWS (Amazon Web Services). Tyto části fyzicky fungovaly celou dobu, ale staly se nedostupnými z jiného důvodu.
Celé to záviselo na řídicí vrstvě umístěné v Google Cloud. Když se vrstva sesypala, začala vyprchávat cache se síťovými trasami. Přibližně 35 minut po začátku výpadku přestalo fungovat i to, co na Googlu vůbec neběželo. Aplikace na AWS a vlastním hardwaru vracely chyby 404, přestože fyzicky existovaly a fungovaly.
Situaci zkomplikoval ještě GitHub, který začal omezovat přihlašování kvůli obrovskému množství opakovaných požadavků ze strany Railway. Plný provoz byl obnoven až kolem 07:58 UTC dne 20. května, tedy přibližně osm hodin po začátku výpadku.
Zakladatel Railway neskrývá překvapení
Zakladatel platformy Railway Jake Cooper reagoval otevřeně a bez diplomatických kliček. Napsal, že je ohromen tím, že Google byl schopen prakticky přes noc zavřít účet, který stojí dva miliony dolarů měsíčně a celkově desítky milionů za celou dobu trvání vztahu.
Připustil přitom architektonickou chybu na straně Railway, tedy to, že závislost na jediném dodavateli mohla kaskádově shodit celou platformu. Zároveň ale poukázal na absurditu situace, kdy platící zákazník nedostane ani elementární varování.
Nejde jen o slova. Cooper oznámil, že Railway přesune Google Cloud z aktivní produkční infrastruktury do role záložního systému. Klíčové komponenty, zejména ty přímo viditelné uživatelům, nesmí být závislé na jediném poskytovateli.
Google a jeho vztah k zákazníkům
Případ Railway není v historii Googlu ojedinělý. V roce 2024 se Google proslavil tím, že smazal veškerou infrastrukturu australského penzijního fondu UniSuper, čímž ohrozil úspory statisíců lidí. I tehdy šlo o omyl automatizovaných systémů.
Technická komunita na diskusní platformě Hacker News komentuje případ Railway v duchu toho, na co vývojáři upozorňují dlouhodobě. Google opakovaně pozastavuje účty skrze neprůhledné automatizované systémy bez lidského posouzení, bez varování a bez vysvětlení.
Railway byla podle nich jen dost velká platforma, aby se případ dostal na titulní stranu. Google k incidentu zatím nevydal veřejné vyjádření a konkrétní příčina pozastavení účtu zůstává neznámá.
Mohlo by vás zajímat
Když se globální síť otřese
Co z toho plyne pro ostatní
Případ Railway je učebnicovým příkladem rizika cloudové koncentrace. Nejde o to, zda firma běží na jednom nebo třech cloudech. Záleží na tom, který cloud ovládá vrstvu, jež říká ostatním, kam posílat provoz. Pokud je tato vrstva u jediného poskytovatele, je celá architektura tak silná, jako je silný tento jeden článek.
Firmy, které provozují kritické systémy v cloudu, by si měly pravidelně klást jednoduchou otázku: jak dlouho by trvalo zotavení, kdyby primární cloudový poskytovatel zítra ráno bez vysvětlení pozastavil jejich účet?
Zdroj: Railway, DEV, Cybernews, The Register, X