Code Orange: Fail Small – Resilienzmaßnahmen nach den jüngsten Störfällen

Am 18. November 2025 kam es im Netzwerk von Cloudflare für etwa zwei Stunden und zehn Minuten zu erheblichen Störungen bei der Bereitstellung von Netzwerk-Traffic. Knapp drei Wochen später, am 5. Dezember 2025, war das Netzwerk erneut beeinträchtigt und konnte für rund 25 Minuten den Traffic von 28 % der hinter dem Netzwerk betriebenen Anwendungen nicht bereitstellen.

Nach beiden Vorfällen haben wir ausführliche Post-Mortem-Beiträge veröffentlicht. Uns ist jedoch bewusst, dass wir noch mehr tun müssen, um Ihr Vertrauen zurückzugewinnen. Heute geben wir Einblick in die laufenden Maßnahmen bei Cloudflare, mit denen wir verhindern wollen, dass es künftig erneut zu Ausfällen dieser Art kommt.

Wir nennen den Plan „Code Orange: Fail Small“. Er spiegelt unser Ziel wider, unser Netzwerk robuster gegenüber Fehlern zu machen, die andernfalls zu einem größeren Ausfall führen könnten. „Code Orange“ bedeutet, dass die Arbeit an diesem Projekt oberste Priorität hat. Zur Einordnung: Einen Code Orange haben wir bei Cloudflare bislang nur einmal zuvor festgelegt – nach einem anderen schwerwiegenden Vorfall, der die höchste Priorität für alle Teams im Unternehmen erforderte. Wir sind der Ansicht, dass die jüngsten Ereignisse denselben Fokus notwendig machen.  Code Orange ist unser Mechanismus, um dies möglich zu machen: Er erlaubt es Teams, bei Bedarf bereichsübergreifend zusammenzuarbeiten, um die erforderlichen Maßnahmen umzusetzen, während andere Arbeiten pausiert werden.

Die Arbeiten im Rahmen von Code Orange gliedern sich in drei zentrale Bereiche:

• Für jede Konfigurationsänderung, die in das Netzwerk verteilt wird, schreiben wir verpflichtend kontrollierte Rollouts vor; analog zu unserem heutigen Vorgehen bei Software-Binary-Releases.

• Wir überprüfen, verbessern und testen die Fehlermodi aller Systeme, die Netzwerk-Traffic verarbeiten, um sicherzustellen, dass sie unter allen Bedingungen ein klar definiertes Verhalten zeigen, einschließlich unerwarteter Fehlerzustände.

• Wir passen unsere internen „Break-Glass“*-Prozesse an und beseitigen zirkuläre Abhängigkeiten, damit wir und unsere Kunden im Störfall schnell handeln und ohne Einschränkungen auf alle Systeme zugreifen können.

Diese Projekte werden im Verlauf schrittweise Verbesserungen bringen, anstatt am Ende eine einzelne umfassende große Änderung umzusetzen. Mit jedem einzelnen Update wird die Resilienz bei Cloudflare erhöht. Am Ende erwarten wir, dass das Cloudflare-Netzwerk deutlich robuster sein wird – auch gegenüber Problemen wie jenen, die in den vergangenen zwei Monaten globale Störfälle ausgelöst haben.

Uns ist bewusst, dass diese Störfälle für unsere Kunden und für das Internet insgesamt belastend sind. Sie entsprechen in keiner Weise unseren eigenen Ansprüchen. Deshalb haben die daraus abgeleiteten Maßnahmen bei Cloudflare für alle oberste Priorität.

^{* „Break-Glass“-Prozesse bei Cloudflare erlauben es bestimmten Personen, ihre Berechtigung unter bestimmten Umständen zu erhöhen, um dringende Aktionen zur Lösung von Szenarien mit hohem Schweregrad durchzuführen.}

Beim ersten Störfall wurden Nutzern, die eine über Cloudflare bereitgestellte Kundenwebsite aufriefen, Fehlerseiten angezeigt, aus denen hervorging, dass Cloudflare keine Antwort auf die Anfrage ausliefern konnte. Beim zweiten Vorfall wurden leere Seiten angezeigt.

Beide Ausfälle folgten einem ähnlichen Muster. Unmittelbar vor jedem Störfall haben wir eine Konfigurationsänderung ohne zeitliche Verzögerung in unseren Rechenzentren in Hunderten von Städten weltweit ausgerollt.

Die Änderung im November war ein automatisches Update unseres Bot-Management-Klassifikators. Wir betreiben verschiedene KI-Modelle, die aus dem Traffic in unserem Netzwerk lernen, um Erkennungsmechanismen für die Identifizierung von Bots zu entwickeln. Diese Systeme werden kontinuierlich aktualisiert, um böswilligen Akteuren zuvorzukommen, die versuchen, unsere Sicherheitsmechanismen zu umgehen und auf Kundenwebsites zuzugreifen.

Beim Störfall im Dezember ging es zunächst um eine Maßnahme zum Schutz unserer Kunden vor einer Schwachstelle im weit verbreiteten Open-Source-Framework React. Dabei haben wir eine Änderung an einem Sicherheitstool vorgenommen, das von unseren Sicherheitsanalysten verwendet wird, um unsere Signaturen zu verbessern. Ähnlich wie bei dringenden Updates im Bot-Management bestand die Notwendigkeit, den Angreifern, die versuchten, diese Schwachstelle auszunutzen, zuvorzukommen. Diese Änderung löste den Beginn des Störfalls aus.

Dabei wurde eine wesentliche Lücke zwischen dem Prozess für Konfigurationsänderungen und dem Verfahren für Software-Updates deutlich. Die Veröffentlichung von Software-Updates erfolgt bei uns kontrolliert und überwacht. Jede neue Binary-Version muss mehrere Freigabestufen erfolgreich durchlaufen, bevor sie weltweit Traffic ausliefern darf. Die Bereitstellung erfolgt zunächst für den Traffic von Mitarbeitenden und wird anschließend sorgfältig schrittweise auf wachsende Anteile unserer weltweiten Kundschaft ausgeweitet, beginnend mit Nutzern der Free-Tarife. Wird in einer Phase eine Anomalie erkannt, kann das Release ohne manuelles Eingreifen zurückgesetzt werden.

Dieses Vorgehen haben wir auf Konfigurationsänderungen bislang nicht angewendet. Im Unterschied zur Veröffentlichung der Kernsoftware, die unser Netzwerk betreibt, modifizieren wir bei Konfigurationsänderungen Parameter, die das Verhalten dieser Software steuern, und können dies unmittelbar tun. Diese Möglichkeit steht auch unseren Kunden zur Verfügung: Wenn Sie in Cloudflare eine Einstellung ändern, wird diese Änderung innerhalb von Sekunden weltweit wirksam.

Diese Geschwindigkeit bietet zwar Vorteile, bringt jedoch auch Risiken mit sich, die wir berücksichtigen müssen. Die beiden jüngsten Störfälle haben gezeigt, dass wir jede Änderung an der Art und Weise, wie wir Traffic in unserem Netzwerk ausliefern, mit derselben geprüften Sorgfalt behandeln müssen wie Änderungen an der Software selbst.

Beide Störfälle hatten eine zentrale Gemeinsamkeit: die weltweite Ausrollung von Konfigurationsänderungen innerhalb von Sekunden. In beiden Fällen führte eine falsche Konfiguration innerhalb von Sekunden zum Ausfall des Netzwerks.

Die Einführung kontrollierter Bereitstellungen für Konfigurationsänderungen – analog zu unserem Vorgehen bei Software-Releases – ist der wichtigste Arbeitsstrang unseres Code-Orange-Plans.

Konfigurationsänderungen bei Cloudflare werden sehr schnell im Netzwerk wirksam. Wenn ein Nutzer einen neuen DNS-Eintrag erstellt oder eine neue Sicherheitsregel anlegt, erreicht diese Änderung innerhalb von Sekunden 90 % der Server im Netzwerk. Ermöglicht wird dies durch eine Softwarekomponente, die wir intern Quicksilver nennen.

Quicksilver wird auch für sämtliche Konfigurationsänderungen genutzt, die von unseren eigenen Teams erforderlich sind. Diese Geschwindigkeit ist grundsätzlich ein Vorteil: Sie erlaubt es uns, schnell zu reagieren und das Verhalten unseres Netzwerks weltweit zügig zu aktualisieren. In beiden Störfällen führte sie jedoch dazu, dass eine fehlerhafte Änderung innerhalb von Sekunden auf das gesamte Netzwerk ausgerollt wurde, anstatt zuvor die vorgesehenen Freigabestufen zur Prüfung zu durchlaufen.

Auch wenn die nahezu sofortige Ausrollung von Änderungen in unserem Netzwerk in vielen Fällen hilfreich ist, ist sie nur selten erforderlich. Derzeit arbeiten wir daran, Konfigurationsänderungen künftig genauso zu behandeln wie Code, indem wir innerhalb von Quicksilver für sämtliche Konfigurationsänderungen kontrollierte Bereitstellungen einführen.

Wir veröffentlichen Software-Updates für unser Netzwerk mehrmals täglich über unser sogenanntes Health Mediated Deployment-System (HMD). In diesem Rahmen muss jedes Team bei Cloudflare, das für einen Dienst verantwortlich ist (also für eine in unser Netzwerk bereitgestellte Softwarekomponente), eine Reihe von Aufgaben erfüllen: Es muss Metriken bestimmen, anhand derer der Erfolg oder Misserfolg einer Bereitstellung bewertet wird, den Rollout-Plan definieren sowie die Schritte festlegen, die im Falle eines Misserfolgs zu ergreifen sind.

Unterschiedliche Dienste weisen leicht unterschiedliche Parameter auf. Einige erfordern längere Wartezeiten, bevor der Rollout auf weitere Rechenzentren ausgeweitet wird, während andere geringere Toleranzen für Fehlerraten haben, selbst wenn dies zu Falsch-Positiven-Signalen führt.

Nach der Bereitstellung beginnt unser HMD-Toolkit, den Plan schrittweise umzusetzen und jeden einzelnen Schritt zu überwachen. Schlägt ein Schritt fehl, wird automatisch ein Rollback eingeleitet. Bei Bedarf kann das zuständige Team zusätzlich benachrichtigt werden.

Sobald Code Orange abgeschlossen ist, werden Konfigurationsupdates dem gleichen Prozess folgen. Wir erwarten, dass wir auf diese Weise Probleme wie jene aus den beiden jüngsten Störfällen frühzeitig erkennen können – lange bevor sie sich zu weitreichenden Störungen entwickeln.

Auch wenn wir optimistisch sind, dass eine bessere Kontrolle von Konfigurationsänderungen mehr Probleme abfängt, bevor sie zu Störfällen werden, sind wir uns bewusst, dass Fehler auftreten können und auftreten werden. Während beider Störfälle weiteten sich Fehler in einem Teil unseres Netzwerks zu Problemen in großen Teilen unseres Technologie-Stacks aus, einschließlich der Kontrollebene, auf die Kunden angewiesen sind, um ihre Nutzung von Cloudflare zu konfigurieren.

Wir müssen kontrollierte, schrittweise Rollouts nicht nur unter geografischen Gesichtspunkten betrachten (also der Ausweitung auf weitere Rechenzentren) oder unter dem Aspekt unterschiedlicher Nutzergruppen (etwa Mitarbeitende oder Kundentypen). Ebenso wichtig ist es, Bereitstellungen so zu gestalten, dass Fehler bei der Ausbreitung zwischen Diensten begrenzt bleiben. Beispielsweise wenn sich ein Problem von einem Produkt wie unserem Bot-Management-Dienst auf ein eigentlich unabhängiges Produkt wie das Dashboard ausweitet.

Vor diesem Hintergrund überprüfen wir derzeit die Schnittstellenverträge zwischen allen kritischen Produkten und Diensten, aus denen unser Netzwerk besteht. Ziel ist es sicherzustellen, dass wir a) davon ausgehen, dass an jeder Schnittstelle Fehler auftreten können, und b) diese Fehler auf die möglichst angemessene und kontrollierte Weise behandeln.

Am Beispiel des Ausfalls unseres Bot-Management-Dienstes gab es mindestens zwei zentrale Schnittstellen, an denen wir den Fehler hätten abfangen können, wenn wir von vornherein davon ausgegangen wären, dass dort ein Fehler auftreten kann. In diesem Fall wäre es unwahrscheinlich gewesen, dass Kunden überhaupt betroffen gewesen wären. Die erste dieser Schnittstellen betraf das Einlesen der beschädigten Konfigurationsdatei. Statt in einen Fehlerzustand zu geraten, hätte es einen sinnvollen Satz validierter Standardwerte geben müssen. Dadurch hätte der Traffic weiterhin durch unser Netzwerk fließen können; im ungünstigsten Fall wäre lediglich die Echtzeit-Feinabstimmung entfallen, die in unsere Machine-Learning-Modelle zur Bot-Erkennung einfließt. Die zweite Schnittstelle lag zwischen der Kernsoftware, die unser Netzwerk betreibt, und dem Bot-Management-Modul selbst. Für den Fall, dass dieses Modul ausfällt – wie es hier geschehen ist –, hätte Traffic nicht standardmäßig verworfen werden dürfen. Stattdessen hätten wir auch hier einen sinnvolleren Standard festlegen können, der es erlaubt hätte, den Traffic mit einer hinreichenden Klassifizierung passieren zu lassen.

Während der Störfälle dauerte es zu lange, bis wir das Problem beheben konnten. In beiden Fällen wurde dies dadurch verschärft, dass unsere Sicherheitssysteme Teammitgliedern den Zugriff auf die Tools verhinderten, die zur Behebung des Problems erforderlich waren. In einigen Fällen bremsten uns zudem zirkuläre Abhängigkeiten, da auch interne Systeme nicht mehr verfügbar waren.

Als Sicherheitsunternehmen sind alle unsere Tools durch Authentifizierungsebenen mit fein granularen Zugriffskontrollen geschützt. Dies dient dem Schutz von Kundendaten und der Verhinderung unbefugten Zugriffs und ist grundsätzlich richtig. Gleichzeitig haben uns unsere bestehenden Prozesse und Systeme in diesen Situationen ausgebremst, obwohl schnelle Reaktionen oberste Priorität hatten.

Zirkuläre Abhängigkeiten wirkten sich auch auf die Kundenerfahrung aus. So war während des Störfalls am 18. November Turnstile, unsere Bot-Lösung ohne CAPTCHA, nicht verfügbar. Da wir Turnstile im Anmeldeprozess für das Cloudflare-Dashboard einsetzen, konnten Kunden ohne aktive Sitzung oder API-Service-Tokens sich in dem Moment nicht bei Cloudflare anmelden, in dem sie dringend kritische Änderungen vornehmen mussten.

Unser Team wird sämtliche „Break-Glass“-Prozesse und die zugehörige Technologie überprüfen und verbessern, um sicherzustellen, dass wir im Bedarfsfall so schnell wie möglich auf die richtigen Tools zugreifen können, ohne dabei unsere Sicherheitsanforderungen zu vernachlässigen. Dazu gehört auch die Überprüfung und Beseitigung zirkulärer Abhängigkeiten oder die Möglichkeit, diese im Störfall schnell zu umgehen. Darüber hinaus werden wir die Häufigkeit unserer Trainingsübungen erhöhen, damit alle Teams die Prozesse gut verstehen, bevor es zu potenziellen Notfallszenarien kommt. 

Auch wenn wir in diesem Beitrag nicht alle internen Arbeiten vollständig abbilden, beschreiben die oben dargestellten Workstreams die zentralen Prioritäten, auf die sich die Teams derzeit konzentrieren sollen. Jeder dieser Workstreams ist mit einem detaillierten Plan hinterlegt, der nahezu alle Product- und Engineering-Teams bei Cloudflare betrifft. Es liegt noch viel Arbeit vor uns.

Bis zum Ende des ersten Quartals – und größtenteils bereits davor – werden wir:

• sicherstellen, dass alle Produktionssysteme im Rahmen des Konfigurationsmanagements durch Health Mediated Deployments (HMD) abgedeckt sind;

• unsere Systeme so weiterentwickeln, dass sie jeweils den für die entsprechenden Produktbereiche geeigneten Fehlerszenarien gerecht werden;

• Prozesse etablieren, die gewährleisten, dass im Notfall die richtigen Personen über die erforderlichen Zugriffsrechte verfügen, um schnell und wirksam reagieren zu können.

Einige dieser Ziele sind dauerhaft. Bei der Einführung neuer Software werden wir kontinuierlich besser mit zirkulären Abhängigkeiten umgehen müssen, und unsere „Break-Glass“-Prozesse werden regelmäßig angepasst werden müssen, um den fortlaufenden Veränderungen unserer Sicherheitstechnologien Rechnung zu tragen.

In den beiden jüngsten Störfällen haben wir unsere Verantwortung gegenüber Nutzern und dem Internet insgesamt nicht erfüllt. Es liegt noch Arbeit vor uns, um dies zu korrigieren. Wir werden im weiteren Verlauf regelmäßig über Fortschritte informieren und danken unseren Kunden und Partnern für die Fragen und das Feedback, die wir erhalten haben.