Im Juni 2025 erlebte Google Cloud einen der schwerwiegendsten Ausfälle seiner jüngeren Geschichte, der mehrere Stunden andauerte und zahlreiche Unternehmen weltweit massiv beeinträchtigte. Hinter diesem Ausfall stand, wie sich später herausstellte, ein verhängnisvoller Fehler innerhalb eines zentralen Systems, der durch das Ignorieren eigener Qualitätsstandards und Kontrollmechanismen verursacht wurde. Diese Situation wirft nicht nur ein Licht auf technische Herausforderungen bei Großanbietern wie Google, sondern offenbart auch strukturelle Schwachstellen in der Softwareentwicklung und Systembetreuung, die selbst globalen Marktführern nicht erspart bleiben. Der Vorfall ereignete sich, als Google am 29. Mai 2025 eine neue Funktion zur Erweiterung der Quotenrichtlinien in das sogenannte „Service Control“-System integrierte.
Dieses System ist essenziell für die Verwaltung von API-Anfragen, deren Autorisierung und die Einhaltung von Richtlinien wie Quotenbegrenzungen. Service Control arbeitet regional verteilt, wobei eine globale Replikation von Richtlinieninformationen die konsistente Umsetzung der Quoten sicherstellt. Dieses System stellt somit eine kritische Schicht dar, die sowohl die Zuverlässigkeit als auch die Sicherheit von Cloud-Diensten gewährleistet. Die neu eingeführte Funktion sollte zusätzliche Quotenprüfungen ermöglichen – ein Schritt, der eigentlich die Qualität und Kontrolle erhöhen sollte. Doch genau hier lag der Knackpunkt.
Während des schrittweisen Rollouts der neuen Funktion kam es zu einem Fehler in einem Codepfad, der nicht wie vorgesehen durch Tests abgesichert und durch Feature Flags geschützt war. Feature Flags dienen in der Softwareentwicklung dazu, neue Funktionen kontrolliert ein- oder auszuschalten und so Fehler frühzeitig erkennen zu können, ohne dass die gesamte Infrastruktur riskiert wird. Google teilte mit, dass dieser kritische Code keine angemessene Fehlerbehandlung besaß, was zu einem sogenannten Null-Pointer-Fehler führte – eine Programmierfehlerart, bei der das System versucht, auf nicht vorhandene Daten zuzugreifen. Dieser Fehler blieb während des Rollouts unentdeckt, da der fehlerhafte Codepfad nur durch das Vorhandensein bestimmter Richtlinien aktiviert wird. Erst am 12.
Juni, als eine Änderung an einer Richtlinie vorgenommen wurde, die unbeabsichtigte leere Felder enthielt, wurde der Fehler ausgelöst. Das System begann in einen Crash-Loop zu geraten, was bedeutet, dass die zuständigen Prozesse ständig abstürzten und neu gestartet wurden. Da das Service Control-System regional verteilt ist, zog sich der Fehler rasch durch die globalen Datenzentren und führte zu massiven Dienstunterbrechungen in vielen Google Cloud Regionen. Die unmittelbaren Auswirkungen waren gravierend. Kunden verloren den Zugriff auf wichtige Cloud-Ressourcen für mindestens drei Stunden.
Besonders betroffen war auch Cloudflare, ein bedeutender Anbieter von Sicherheits- und Performance-Dienstleistungen im Internet. Durch die Unterbrechungen bei Google Cloud kam es bei Cloudflare selbst zu Dienstwacklern, die wiederum deren Kunden vor Herausforderungen stellten. Dieser Dominoeffekt zeigt die starke Verwobenheit moderner Cloud-Infrastrukturen und unterstreicht, wie ein Fehler in einer Komponente eine Kettenreaktion von Ausfällen auslösen kann. Google selbst reagierte schnell, indem das Site Reliability Engineering Team den Vorfall innerhalb von zwei Minuten erkannte und nach zehn Minuten die Problemursache identifizierte. Dennoch gestaltete sich die Wiederherstellung auf Grund von Infrastrukturüberlastungen in einzelnen großen Regionen schwierig und zog sich in manchen Fällen auf fast drei Stunden.
Das lag daran, dass mit jedem Neustart der Service Control Komponenten eine „Herdenwirkung“ auf deren abhängige Infrastruktur entstand, die nicht für einen solchen Ansturm ausgelegt war. Ein wichtiger Punkt, den Google offen zugab, war, dass die fehlerhafte Funktion keine Feature Flag hatte, durch die man das Problem im Vorfeld hätte isolieren können. Dadurch wurde die Chance verpasst, den Bug bereits in Testumgebungen zu finden. Fehlende oder ungenügende Fehlerbehandlungen hatten das Risiko zusätzlich erhöht, weil der Null-Pointer-Fehler nicht abgefangen wurde und stattdessen zum Absturz der gesamten Komponente führte. Aus operativer Sicht sind solche Vorfälle für Cloud-Anbieter keine Seltenheit, auch wenn sie meist sehr viel länger gut funktionieren.
Die Komplexität der Systeme und die Geschwindigkeit von Softwareänderungen schaffen eine permanente Herausforderung. Googles Umgang mit dem Vorfall beinhaltet daher nicht nur eine öffentliche Entschuldigung, sondern auch konkrete Ankündigungen zur Verbesserung der betrieblichen Prozesse. Dazu zählt insbesondere die Verbesserung der externen Kommunikationswege. Kunden sollen zukünftig schneller und umfassender über Zwischenfälle informiert werden, um eigenständige Reaktionen und Maßnahmen zu ermöglichen. Ebenso plant Google, die eigenen Monitoring- und Kommunikationssysteme so zu gestalten, dass sie auch im Falle eines Ausfalls der primären Systeme stets funktionsfähig bleiben und einen reibungslosen Informationsfluss sicherstellen.
Diese Änderungen können als eine implizite Anerkennung gewertet werden, dass schwere Ausfälle sich nicht vollständig vermeiden lassen und das Krisenmanagement verstärkt in den Fokus rückt. Gerade bei Cloud-Services, die sich über komplexe und vernetzte Infrastruktur erstrecken, sind absolute Ausfallsicherheit und Null-Fehler-Toleranz schwer realisierbar. Daraus ergibt sich für Kunden eine wichtige Erkenntnis: Abhängigkeiten von einzelnen Anbietern bergen immer ein gewisses Risiko, das es durch Diversifikation oder Notfallstrategien zu minimieren gilt. Allerdings zeigt der Fall auch, dass selbst die größten Technologieunternehmen mit enormen Ressourcen und umfangreichen Qualitätskontrollprozessen nicht komplett vor Fehlern geschützt sind. Die Balance zwischen Innovation und stabiler Bestandsleistung ist heikel.
Während neue Funktionen und Updates essenziell sind, um den Kunden moderne und leistungsfähige Dienste anbieten zu können, müssen diese stets ausreichend getestet und abgesichert sein. Vor allem das Fehlen eines Feature Flags bei der kritischen Änderung war ein entscheidender Faktor. Feature Flags erlauben es Entwicklern, neue oder risikobehaftete Funktionen schrittweise und kontrolliert zu aktivieren. Ohne diesen Schutzmechanismus wurden die fehlerhaften Codes nicht vorab identifiziert und konnten ungehindert in Produktion gelangen. Die konsequente Nutzung von Feature Flags und automatisierten Tests gehört inzwischen zu den bewährten Praktiken moderner Softwareentwicklung.
Google hat mit seinem transparenten und detaillierten Incident Report zu dem Vorfall seine Verantwortung gezeigt und bietet interessante Einblicke in die technische Herkunft und die operativen Abläufe bei Krisenmanagement. Gleichzeitig öffnet er die Diskussion über das allgemeine Risiko von Cloud-Diensten und die notwendigen Mechanismen zur Sicherstellung von Zuverlässigkeit. Für Unternehmen, die auf Cloud-Ressourcen angewiesen sind, ist der Fall ein weiterer Weckruf, eigene Notfallpläne zu prüfen, umfangreiche Testumgebungen zu pflegen und das Monitoring zu optimieren. Im Idealfall sollten mehrere Anbieter und Redundanzen für kritische Dienste berücksichtigt werden, um bei Störungen möglichst schnell ausweichen zu können. Zusammenfassend lässt sich sagen, dass der Google Cloud Ausfall durch Vernachlässigung essentieller Qualitätskontrollen entstand und trotz schneller Reaktion und Behebung eine breite Welle von Störungen auslöste.
Die Lehren aus dem Vorfall umfassen sowohl Veränderungsbedarf bei der Softwareentwicklung als auch bei der Kundenkommunikation und dem Krisenmanagement. Der Vorfall zeigt, dass Kontinuität und Zuverlässigkeit in der digitalen Infrastruktur nie selbstverständlich sind und ständiger Aufmerksamkeit bedürfen – gerade in einer zunehmend cloudbasierten Welt.
