Railway: Eine GCP-Kontosperrung legte Railway 8 Stunden lang lahm

Unternehmen und Produkt

Railway ist eine Infrastrukturplattform, mit der Entwickler Anwendungen, Datenbanken, Services und APIs bereitstellen, hosten und verwalten können, ohne komplexe Cloud-Infrastruktur manuell konfigurieren zu müssen.

Um hohe Verfügbarkeit und Resilienz sicherzustellen, führt die Plattform Workloads über mehrere Umgebungen hinweg aus, darunter Google Cloud Platform (GCP), Amazon Web Services (AWS) und die eigene Railway-Metal-Infrastruktur.

Trotz dieser verteilten Architektur bestand in der Netzwerk-Control-Plane von Railway weiterhin eine feste Abhängigkeit von Google Cloud. Die Edge-Routing-Schicht war nach wie vor auf eine in GCP gehostete Control-Plane-API angewiesen, um Workloads zu erkennen und Routing-Tabellen zu aktualisieren.

Was war passiert

Am 19. Mai um 22:20 Uhr UTC sperrte Google Cloud das Produktionskonto von Railway fälschlicherweise durch eine automatisierte Maßnahme – ohne vorherige proaktive Kontaktaufnahme oder Warnung. Dadurch wurde die GCP-abhängige Infrastruktur von Railway sofort deaktiviert, einschließlich Dashboard, API, Datenbanken, Compute-Infrastruktur und Teilen der Netzwerkschicht.

Nutzer sahen daraufhin 503-Fehler im Dashboard und in der API, darunter Meldungen wie „no healthy upstream“ und „unconditional drop overload“. Viele Nutzer konnten sich außerdem nicht mehr einloggen.

Bemerkenswert ist der Incident, weil er eine versteckte Schwachstelle in der Multi-Cloud-Architektur von Railway offenlegte. Zunächst blieben Kunden-Workloads, die auf AWS und Railway Metal liefen, online. Die Edge-Proxys von Railway waren jedoch auf Routing-Informationen aus einer auf GCP gehosteten Netzwerk-Control-Plane-API angewiesen. Sobald die zwischengespeicherten Routendaten abgelaufen waren, konnte die Edge-Schicht keine Routen zu aktiven Instanzen mehr auflösen.

In der Folge gaben auch Workloads außerhalb von GCP 404-Fehler zurück. Zum Höhepunkt der Auswirkungen waren damit alle Railway-Workloads in allen Regionen nicht mehr erreichbar.

Die Wiederherstellung brachte zusätzliche Komplexität mit sich. Der wiederhergestellte Zugriff auf das GCP-Konto reichte nicht aus, um die Plattform sofort wieder online zu bringen. Railway musste Persistent Disks, Compute-Instanzen, Netzwerkkomponenten, Edge-Routing und die Orchestrierungsschicht Schritt für Schritt wiederherstellen. Während der Wiederherstellung löste eine große Zahl erneut gesendeter Anfragen außerdem GitHub-Rate-Limits für die OAuth- und Webhook-Integrationen von Railway aus. Dadurch entstanden vorübergehend zusätzliche Blocker für Logins und Builds.

Timeline

• 19. Mai, 22:10 Uhr UTC: Das automatisierte Monitoring erkennt fehlgeschlagene API-Health-Checks und löst eine Alarmierung für die Bereitschafts-Engineers aus.
• 19. Mai, 22:11 Uhr UTC: Das Railway-Dashboard beginnt, 503-Fehler zurückzugeben. Nutzer können sich nicht mehr einloggen.
• 19. Mai, 22:19 Uhr UTC: Railway identifiziert die Ursache: Google Cloud hatte das Produktionskonto gesperrt.
• 19. Mai, 22:22 Uhr UTC: Railway eröffnet ein P0-Ticket bei Google Cloud und kontaktiert direkt den zuständigen GCP Account Manager.
• 19. Mai, 22:29 Uhr UTC: Railway erklärt den Incident offiziell. Der Zugriff auf das GCP-Konto wird wiederhergestellt, Compute-Instanzen und Persistent Disks bleiben jedoch weiterhin offline.
• 19. Mai, 22:35 Uhr UTC: Zwischengespeicherte Netzwerkrouten beginnen abzulaufen. Workloads auf Railway Metal und AWS geben aufgrund fehlgeschlagener Routenauflösung 404-Fehler zurück.
• 19. Mai, 23:09 Uhr UTC: Die erste Persistent Disk ist wieder online.
• 19. Mai, 23:54 Uhr UTC: Alle Persistent Disks erreichen den Status „ready“, das Netzwerk bleibt jedoch weiterhin offline.
• 20. Mai, 00:39 Uhr UTC: Die Disks werden als bereit bestätigt. Die Wiederherstellung bleibt jedoch blockiert, bis Google Cloud die Netzwerkinfrastruktur wiederhergestellt hat.
• 20. Mai, 01:30 Uhr UTC: Compute-Instanzen beginnen sich zu erholen.
• 20. Mai, 01:38 Uhr UTC: Die Netzwerkinfrastruktur ist wiederhergestellt und der Edge-Traffic läuft wieder an.
• 20. Mai, 01:57 Uhr UTC: Orchestrierung und Build-Infrastruktur sind wieder online. Deployments werden vorübergehend pausiert, um eine Überlastung der Plattform zu verhindern.
• 20. Mai, 02:04 Uhr UTC: Compute-Hosts werden schrittweise wieder online gebracht.
• 20. Mai, 02:47 Uhr UTC: GitHub beginnt, die OAuth- und Webhook-Integrationen von Railway durch Rate-Limits zu begrenzen. Dadurch werden einige Logins und Builds vorübergehend blockiert.
• 20. Mai, 02:55 Uhr UTC: Das Dashboard ist wieder erreichbar.
• 20. Mai, 03:59 Uhr UTC: Deployments werden über alle Tiers hinweg verarbeitet.
• 20. Mai, 04:00 Uhr UTC: API, Dashboard und OAuth-Endpunkte werden als funktionsfähig bestätigt. Die verbleibenden Workloads werden weiter wiederhergestellt.
• 20. Mai, 06:14 Uhr UTC: Der Incident wechselt in die Monitoring-Phase.
• 20. Mai, 07:58 Uhr UTC: Der Incident ist vollständig behoben.

‍

Time to Detect (TTD): Innerhalb weniger Minuten. Das Monitoring erkannte um 22:10 Uhr UTC fehlgeschlagene API-Health-Checks, und die Engineers identifizierten die Ursache um 22:19 Uhr UTC.

Time to Resolve (TTR): Rund 8 Stunden bis zum Erreichen der Monitoring-Phase und 9 Stunden 38 Minuten bis zur vollständigen Behebung.

Wer war betroffen?

Der Ausfall betraf Railway-Kunden in allen Regionen. Nutzer verloren den Zugriff auf Dashboard, API, Deployment-Management und Build-Trigger. Zunächst war die Auswirkung auf die in GCP gehostete Infrastruktur beschränkt. Nachdem jedoch die Edge-Routing-Caches abgelaufen waren, weitete sich der Ausfall auch auf Workloads in AWS und Railway Metal aus. Zum Höhepunkt des Incidents waren alle Workloads in allen Regionen nicht mehr erreichbar.

Wie reagierte Railway?

Railway reagierte schnell und stützte sich dabei stark auf automatisiertes Monitoring. Nachdem die Engineers wegen fehlgeschlagener API-Health-Checks alarmiert worden waren, identifizierten sie die GCP-Sperrung innerhalb von neun Minuten und eskalierten das Problem sofort über ein P0-Ticket sowie über den zuständigen GCP Account Manager.

Da die Wiederherstellung des Kontozugriffs die Plattform nicht automatisch wieder online bringen würde, führte das Team eine kontrollierte Wiederherstellung Schicht für Schicht durch. Persistent Disks, Compute-Instanzen, Netzwerkkomponenten und Edge-Routing wurden systematisch validiert. Um einen Folgeausfall durch aufgestaute Vorgänge zu verhindern, pausierte Railway Deployments gezielt und baute den Rückstau schrittweise ab. Außerdem kümmerte sich das Team um das sekundäre Problem mit den GitHub-Rate-Limits, das OAuth-Logins und Webhook-basierte Builds vorübergehend beeinträchtigte. Entscheidend ist: Railway übernahm die volle Verantwortung für die Architekturschwachstelle, durch die die Maßnahme eines einzelnen Anbieters einen globalen Ausfall verursachen konnte.

Wie kommunizierte Railway?

Railway veröffentlichte einen umfassenden und transparenten Incident Report. Darin beschrieb das Unternehmen die Timeline, die Auswirkungen, die Ursache und den schrittweisen Wiederherstellungsprozess im Detail. Statt die gesamte Verantwortung auf Google Cloud abzuwälzen, räumte Railway die versteckte Abhängigkeit im eigenen Multi-Cloud-Netzwerk ausdrücklich ein. Indem Railway die Verantwortung für die eigenen Anbieterentscheidungen übernahm und klarstellte, dass die Uptime der Kunden letztlich in der eigenen Verantwortung liegt, lieferte das Unternehmen ein sehr glaubwürdiges und handlungsorientiertes Postmortem.

Wichtige Erkenntnisse für andere Teams

• Multi-Cloud bedeutet nicht automatisch Resilienz: Die Verteilung von Workloads auf GCP, AWS und Bare Metal ist wirkungslos, wenn eine kritische Control-Plane-Abhängigkeit an einen einzelnen Anbieter gebunden ist. Unternehmen sollten prüfen, ob ihre Failover-Architektur den Ausfall eines gesamten Anbieters übersteht – nicht nur den Ausfall einer Zone.
• Single-Provider-Abhängigkeiten aus dem Hot Path entfernen: Routing, Service Discovery, Authentifizierung und Deployment-Orchestrierung sollten nicht von einem einzigen Cloud-Anbieter abhängen, damit Kunden-Workloads erreichbar bleiben.
• Cache-Ablaufzeiten können Teilausfälle in globale Ausfälle verwandeln: Zwischengespeicherte Routendaten verschafften Railway vorübergehend einen Puffer. Teams sollten ihre Time-to-Live-Werte (TTL) für Caches genau kennen und verstehen, wie sich das System verhält, wenn diese Caches ablaufen.
• Wiederherstellung muss schrittweise und kontrolliert erfolgen: Ein komplexes System ist nicht automatisch wiederhergestellt, sobald der Zugriff wieder möglich ist. Teams sollten Wiederherstellungs-Runbooks entwickeln und testen, um Infrastruktur Schicht für Schicht wiederherzustellen – von Disks über Netzwerk und Compute bis hin zu kundenorientierten Services.
• Sekundäre Ausfälle während der Wiederherstellung einplanen: Retry Storms und aufgestaute Backlogs können Systeme während der Wiederherstellung überlasten. Webhook-Spitzen und Rate-Limits von Drittanbieter-APIs wie GitHub sollten daher in Disaster-Recovery-Plänen berücksichtigt werden.

Kurzfassung

Am 19. Mai 2026 kam es bei Railway zu einem plattformweiten SEV-1-Ausfall, nachdem Google Cloud das Produktionskonto des Unternehmens fälschlicherweise gesperrt hatte. Obwohl Railway neben GCP auch AWS und Bare Metal nutzt, weitete sich der Ausfall weltweit aus, da Edge-Proxys für das Routing des Traffics auf eine in GCP gehostete Control-Plane-API angewiesen waren. Sobald die zwischengespeicherten Routen abgelaufen waren, waren alle Workloads nicht mehr erreichbar. Nach einem schrittweisen, achtstündigen Wiederherstellungsprozess kündigte Railway an, Single-Vendor-Abhängigkeiten aus der Data Plane zu entfernen und die Control Plane für echte Multi-Cloud-Resilienz neu zu gestalten.

So kann ilert helfen

Incidents wie der Ausfall bei Railway zeigen, wie schnell ein anbieterseitiger Fehler durch versteckte Abhängigkeiten zu einem plattformweiten Ausfall eskalieren kann. ilert unterstützt Engineering- und Infrastrukturteams dabei, schneller zu reagieren, nahtlos zusammenzuarbeiten und während kritischer Ereignisse klar zu kommunizieren.

• Intelligente Alarmierung: API-Health-Checks, Dashboard-Ausfälle, Edge-Routing-Fehler sowie Cloud-Provider- oder Monitoring-Alerts werden in einen zentralen Incident-Workflow geleitet. So können Teams kaskadierende Ausfälle früher erkennen.
• Kontextbezogene Gruppierung von Alarmierungen: Zusammengehörende Alarmierungen aus Control Plane, Edge-Proxys, Deployment-Systemen und Drittanbieter-Integrationen werden in einem Incident gebündelt. Das reduziert die Alarmflut und gibt Respondern einen klareren Überblick über die Fehlerkette.
• Automatisierte Eskalation: Mit Eskalationsrichtlinien und Dienstplänen werden automatisch die richtigen Infrastruktur-, Plattform- oder Netzwerk-Engineers benachrichtigt, sobald kritische Routing- oder Control-Plane-Alarmierungen ausgelöst werden.
• Statusseiten: Kunden bleiben während länger andauernder, providerbedingter Ausfälle durch klare Incident-Updates informiert, während sich Engineering-Teams auf die Wiederherstellung konzentrieren können.
• Post-Incident Review: Incident-Timelines, Aarmierungs-Historie, Responder-Notizen und Stakeholder-Updates helfen dabei, die Ereigniskette zu rekonstruieren und versteckte Abhängigkeiten vor dem nächsten Ausfall zu erkennen.