Eine Zone, sechs Stunden: was der Google-Cloud-Ausfall in London zeigt
Ein Stromausfall in einer Google-Cloud-Zone in London störte am 20. Oktober stundenlang Banken, auch Revolut in der Schweiz. Was versagte, was zu prüfen ist.
Am Dienstag, 20. Oktober 2026, fiel in einer der drei Zonen der Google-Cloud-Region London der Strom aus. Während mehrerer Stunden waren Banken, Paketdienste und Onlineshops in Grossbritannien ganz oder teilweise nicht erreichbar, und auch Bankkunden auf dem europäischen Festland bekamen es zu spüren, darunter die Kundinnen und Kunden von Revolut in der Schweiz. Die Ursache war laut Google ein Fehler in der Technik, die einen Stromausfall harmlos machen soll.
Was passiert ist
Um 05:53 UTC wurde die Netzstromversorgung des Rechenzentrums hinter der Zone europe-west2-b unterbrochen. Die Batterien übernahmen die Last, wie vorgesehen. Die Generatoren nicht. Laut dem vorläufigen Störungsbericht von Google lösten weder die primäre noch die Reservesteuerung, welche die Generatoren starten und die Last auf sie umschalten, den Start aus. Um 06:00 UTC, 08:00 Uhr Schweizer Zeit, waren die Batterien leer, und Server, Netzwerk-Switches und lokaler Speicher dieser Zone fielen aus.
Google beziffert die Störung auf sechs Stunden und zehn Minuten, bis 12:10 UTC, als wieder mehr als 99 % der virtuellen Maschinen von Compute Engine liefen. Die Abschlussmeldung folgte um 14:03 UTC, der vorläufige Bericht am 22. Oktober. Ein Schlussbericht mit vorbeugenden Massnahmen steht noch aus.
Der Stromausfall traf eine Zone. Die Folgen reichten in die ganze Region. Laut dem Bericht von Google hat der umgeleitete Verkehr die verfügbare Rechen- und Verarbeitungskapazität in den anderen Zonen ausgeschöpft, und Prüfungen in der Steuerungsebene, die über Zonengrenzen hinweg laufen, haben die Störung weiter verbreitet. Regional Persistent Disk und Cloud SQL werden unter den Diensten mit Problemen bei der Umschaltung und mit Leistungseinbussen genannt. Während der Störung war der einzige Workaround von Google, Arbeitslasten in eine andere Zone oder Region zu verschieben, sofern machbar.
Die Liste der Betroffenen war lang. Reuters berichtete von Störungen bei Revolut, Lloyds und HSBC. Die britische Justizverwaltung meldete Probleme mit der Videoplattform, die sie für einen Teil der Fernverhandlungen nutzt. In der Schweiz meldete Revolut, das hier 1,3 Millionen Kundinnen und Kunden hat, laut Netzwoche Probleme bei Kartenzahlungen, Überweisungen und Bargeldbezügen. Um 17 Uhr Schweizer Zeit, eine Stunde nachdem Google die Störung für beendet erklärt hatte, wies die Statusseite von Revolut noch 27 seiner Dienste in der Schweiz als teilweise nicht verfügbar aus. Auch Hostinger und MongoDB Atlas meldeten Probleme im Zusammenhang mit dem Ausfall.
Die Aufsicht reagierte innert eines Tages. Die Europäische Bankenaufsichtsbehörde (EBA) nahm Kontakt mit Google Cloud auf, um die Folgen für Finanzunternehmen in der EU zu beurteilen. Google gehört zu den 19 Anbietern, welche die Europäischen Aufsichtsbehörden im November 2025 unter DORA als kritische IKT-Drittdienstleister eingestuft haben. Die EBA fügte einen Satz an, den man zweimal lesen sollte: Die Einstufung nehme dem Anbieter die Verantwortung für das Störungsmanagement nicht ab und entbinde Finanzunternehmen nicht von ihren eigenen aufsichtsrechtlichen Pflichten. Google steht für seine Störung ein. Die Bank steht weiterhin für ihren Dienst ein, wer auch immer die Server betreibt.
Was es für ein Unternehmen oder eine Verwaltung bedeutet
Die erste Lehre steht in der Dokumentation von Google selbst: Eine Zone ist als einzelner Fehlerbereich innerhalb einer Region zu betrachten. Am 20. Oktober war die Zone ein Rechenzentrum, dessen Generatoren nicht ansprangen. Alles, was nur in einer Zone läuft, eine einzelne virtuelle Maschine, eine Disk, eine Datenbank ohne Replikat anderswo, teilt das Schicksal der Generatoren dieses Gebäudes. Das ist keine Besonderheit von Google. Die meisten Rechenzentren verlassen sich auf dieselbe Kette aus Batterien, Generatoren und automatischer Steuerung, und diese Kette kann überall reissen.
Die zweite Lehre ist unbequemer. Einen Dienst auf mehrere Zonen zu verteilen, reichte am 20. Oktober nicht. Als eine Zone wegfiel, wanderte die Arbeit in die beiden anderen, und dort wurde die Kapazität knapp. Ein Plan, der mit freiem Platz anderswo rechnet, funktioniert nur, wenn dieser Platz reserviert ist und die Umschaltung unter Last erprobt wurde.
Die dritte betrifft die Zeit. Google kommt auf sechs Stunden und zehn Minuten. Für die Kundinnen und Kunden von Revolut in der Schweiz dauerte es länger. Ihr Ausfall dauert, bis Ihr eigener Dienst wieder läuft, nicht bis die Statusseite Ihres Anbieters grün wird. Die Wiederherstellung bei Google umfasste gestaffelte Neustarts, abgearbeitete Rückstände sowie Prüfungen von Zustand und Speicher, und jeder Kunde hat seine eigene Version dieser Liste.
Die vierte betrifft die Kette. Menschen und Firmen, die nie einen Vertrag mit Google unterschrieben haben, waren trotzdem betroffen, weil ihre Bank oder ihr Hostinganbieter dort läuft. Die Frage ist, ob Sie wissen, von welcher Cloud Ihre eigenen Lieferanten abhängen, und in wie vielen Zonen.
Wo Elchi Studios steht
Unsere Dienste und die Firmenwebsites, die wir betreiben, laufen auf unserem eigenen Cluster: acht Server bei fünf Anbietern in vier Ländern, der Schweiz, Deutschland, den Niederlanden und Frankreich. Ich habe diese Verteilung gewählt, damit der Verlust eines Gebäudes oder einer Firma nicht den ganzen Dienst mitreisst.
- Zwei Eingänge, wo die Verbindung eines Browsers ankommt: Hetzner in Falkenstein und UpCloud in Amsterdam. Fällt einer aus, übernimmt der andere den Verkehr.
- Zwei Anwendungsknoten, die gleichzeitig bedienen: Infomaniak in Genf und Scaleway in Amsterdam.
- Drei Datenbankknoten, in Frankfurt, Nürnberg und Paris. Eine Änderung gilt erst als geschrieben, wenn alle drei sie halten.
Am wenigsten verteilt sind gespeicherte Dateien. EMX speichert Nachrichten und Anhänge verschlüsselt in Genf, und Profilbilder und Logos liegen im Objektspeicher bei Infomaniak, mit einer nächtlichen Kopie bei Scaleway. Eine nächtliche Kopie schützt davor, Dateien zu verlieren. Sie hält sie nicht erreichbar, solange der ursprüngliche Standort ausgefallen ist.
Zwei weitere Punkte, im Sinne des Satzes der EBA. Erstens haben wir noch keinen ganzen Standort unter Last abgeschaltet und das Ergebnis veröffentlicht. Bis wir das getan haben, ist der Aufbau oben ein Plan und keine Messung, und das Ergebnis erscheint in diesem Journal, wie auch immer es ausfällt. Zweitens ist der Ausfall eines Anbieters, den wir gewählt haben, unser Ausfall. Für gehostete Kundenprojekte versprechen wir 99,99 % pro Jahr, und Ausfälle der Hosting- und DNS-Anbieter, die wir ausgesucht haben, gehen zulasten dieser Zusage, wie wir erklärt haben, als wir dieses Versprechen von 99,999 % gesenkt haben. Vier unabhängige Monitore, die an verschiedenen Orten laufen, überwachen unsere Dienste, und status.elchi.dev veröffentlicht, was sie messen.
Was Sie diese Woche prüfen sollten
- Listen Sie auf, was nur in einer Zone läuft. Virtuelle Maschinen, Disks, Datenbanken ohne Replikat, ein Cache, eine Warteschlange. Halten Sie für jedes Element fest, was mit Ihrem Dienst geschieht, wenn diese Zone für sechs Stunden verschwindet.
- Prüfen Sie, ob die verbleibenden Zonen die Last tragen. Wenn Ihre Umschaltung darauf baut, dass anderswo Kapazität frei ist, reservieren oder testen Sie diese. Am 20. Oktober wurde die Kapazität in den anderen Londoner Zonen knapp.
- Suchen Sie Abhängigkeiten über Zonengrenzen hinweg. Eine Steuerungsebene, ein Konfigurationsspeicher, ein Dienst für Geheimnisse oder eine Lizenzprüfung an nur einem Ort kann verhindern, dass der Rest startet.
- Fragen Sie Ihre Lieferanten, wo sie laufen. Ihren Zahlungsanbieter, Ihren Hostinganbieter, Ihren Datenbankdienst: welcher Anbieter, wie viele Zonen, wie viele Regionen, und wie sie Sie informieren, wenn etwas ausfällt.
- Messen Sie von aussen. Ein Monitor ausserhalb Ihrer eigenen Infrastruktur zeigt Ihnen, wann Ihre Kunden betroffen sind. Die Statusseite Ihres Anbieters zeigt Ihnen, wann der Anbieter betroffen ist. Am 20. Oktober waren das verschiedene Zeitpunkte.
- Lesen Sie die Verfügbarkeitsklausel Ihrer Verträge. Prüfen Sie die Zahl, wie sie gemessen wird und ob Ausfälle der Lieferanten Ihres Anbieters zählen oder ausgenommen sind.
- Planen Sie für eine ganze Region. Google selbst rät zu einem Notfallplan für den Verlust einer Region. Ein Backup in einer anderen Region zählt erst, wenn eine Wiederherstellung daraus erprobt wurde.
Quellen
- Preliminary Incident Report: multiple services in europe-west2 (London), Google Cloud Service Health, gelesen am
- Geography and regions, Google Cloud, gelesen am
- Google Cloud says a 'power event' caused today's outage, The Register, gelesen am
- Europe's financial regulators query Google over cloud outage that hit banks, Reuters, via Global Banking & Finance Review, gelesen am
- European banks, websites hit as Google Cloud data centre goes offline for hours, ABC News, gelesen am
- Störung bei Google Cloud beeinträchtigt zahlreiche Dienste in der Schweiz und Europa, Netzwoche, gelesen am
- Grossausfall bei Google Cloud, Inside IT, gelesen am
- EU regulators designate critical tech providers under DORA, Pinsent Masons Out-Law, gelesen am
- The October 20, 2026 Google Cloud europe-west2 Outage, IncidentHub, gelesen am
Geschrieben von Samuel Krauss, Founder. Abgelegt unter hosting, availability, cloud, operations.
Übersetzt aus dem Englischen. Zum englischen Original