Cloudflare: Ausfall eines Drittanbieter-Speichers

Das Unternehmen

Cloudflare ist ein weltweit führender Anbieter für Internet-Sicherheit, Performance und Systemzuverlässigkeit. Die Plattform schützt und verbessert die Geschwindigkeit von Millionen Websites, APIs und Internetanwendungen mit einer integrierten Tool-Suite darunter ein erstklassiges Content Delivery Network (CDN), DNS-Auflösung, DDoS-Mitigation und Zero Trust Security. Entwickler und Unternehmen vertrauen auf Produkte wie Workers und Workers KV für serverloses Computing, Edge-Speicher und verteilte Anwendungslogik.

Was passierte während der Cloudflare-Störung?

​​ Cloudflare eine schwerwiegende Störung, die 2 Stunden und 28 Minuten dauerte. Ursache war ein Ausfall des Drittanbieter-Speicher-Backends, das Workers KV betreibt – eine zentrale Abhängigkeit vieler Kerndienste.

‍
Die Störung betraf weltweit Kunden, die Cloudflares Zero Trust, Serverless- und Edge-Plattformen nutzen. Dienste wie Access, WARP, Gateway, Turnstile, Stream, Workers AI und Teile des Dashboards waren beeinträchtigt. Bei einigen kam es zu fast vollständigen Ausfällen (z. B. 100 % Fehler bei Access-Logins und Stream Live), bei anderen trat nur eine teilweise Beeinträchtigung auf (z. B. 97 % Erfolgsrate bei Images, erhöhte CDN-Latenz).

‍
DNS, Magic WAN, Transit und WAF blieben zwar online, es wurden jedoch Auswirkungen auf nachgelagerte Dienste festgestellt.

Timeline

Wann begann die Cloudflare-Störung?

‍

Der Incident begann um 17:52 UTC, als das WARP-Team von Cloudflare neue Fehler bei der Geräte-Registrierung feststellte. Interne Alarmierungen wurden umgehend ausgelöst und um 18:05 UTC wurde das Access-Team wegen steigender Fehlerraten benachrichtigt. Nachdem mehrere Services ihre SLOs überschritten, wurde der Incident um 18:06 UTC als P1 eingestuft.

‍

Wie wurde der Cloudflare-Incident erkannt und eskaliert?

‍

Mit zunehmenden globalen Auswirkungen wurde um 18:21 UTC auf P0 eskaliert. Die Gegenmaßnahmen starteten kurz darauf: Um 18:43 UTC wurde Access von Workers KV entkoppelt, gefolgt von Graceful Degradation bei Gateway um 19:09 UTC und Load Shedding um 19:32 UTC.

‍

Wann wurde die Cloudflare-Störung behoben?

‍

Die Wiederherstellung begann um 20:23 UTC, als der Speicheranbieter wieder online ging. Access und Device Posture liefen ab 20:25 UTC wieder normal, und der Incident war um 20:28 UTC vollständig gelöst.

MTTD: ca. 13 Minuten
MTTR: ca. 2 Stunden 36 Minuten

‍

Wie hat Cloudflare auf die Störung reagiert?

Das Engineering-Team von Cloudflare leitete schnell die Eskalation ein und folgte den Runbooks für kritische Systeme. Die Gegenmaßnahmen erfolgten zügig, aber die Erkennung begann erst bei Ausfällen in nachgelagerten Diensten, und Tools für die Wiederherstellung befanden sich noch in Entwicklung. Zukünftige Verbesserungen, wie im Postmortem-Blog beschrieben, sollen die Reaktionszeiten durch bessere Observability und Fallback-Designs weiter verkürzen. Die Reaktion des Teams spiegelte eine lernorientierte Kultur ohne Schuldzuweisungen wider.

Wer war von der Cloudflare-Störung betroffen und wie schwerwiegend war sie?

Die Störung betraf einen großen Teil des Cloudflare-Ökosystems und sowohl Unternehmenskunden als auch Endnutzer weltweit. Während DNS, Cache und WAF stabil blieben, fielen viele Zero Trust-, Serverless- und Entwickler-Produkte vollständig oder fast vollständig aus.

‍

Am stärksten betroffen waren:

‍

• Access: 100 % Ausfall bei allen identitätsbasierten Logins.
• WARP: Neue Client-Verbindungen schlugen fehl, Policy-Prüfungen funktionierten für viele Nutzer nicht.
• Stream Live & Workers AI: Bis zu 100 % Fehlerrate.
• Pages Builds, Zaraz, AutoRAG, Queues, Browser Rendering: komplett offline.
• Realtime SFU & TURN: Traffic sank auf 20 %.
• Gateway, Dashboard, Turnstile: Starke Beeinträchtigungen bei identitätsbezogenen Funktionen.

‍
Teilweise Ausfälle:

‍

• Cloudflare Images: 97 % Erfolgsrate, aber Batch-Uploads schlugen fehl.
• CDN: Größtenteils stabil, aber mit lokaler Latenz und Routing-Problemen in einzelnen Städten.
• Durable Objects & D1: Fehlerraten erreichten vor der Wiederherstellung bis zu 22 %.

Wie hat Cloudflare während der Störung kommuniziert?

Cloudflare hat während der gesamten Störung transparent und regelmäßig kommuniziert – vor allem über die Statusseite und später mit einem Postmortem. Die Updates kamen zeitnah und wurden je nach Schweregrad angepasst. Die Kommunikation verlief teamübergreifend klar, aber Nutzer mit indirekten Abhängigkeiten hatten anfangs möglicherweise keinen Einblick in die eigentliche Ursache. Außerdem führten Secure-by-Design-Richtlinien kurzfristig zu Ausfällen ohne Fallback-Möglichkeiten.

‍
Wie das SRE-Playbook von Google betont, braucht gute Incident-Kommunikation nicht nur Genauigkeit, sondern auch gutes Timing, passenden Ton und Empathie. Cloudflare erfüllte die meisten dieser Anforderungen, aber die Sichtbarkeit für Edge Cases kann weiter verbessert werden.

Welche Muster hat die Cloudflare-Störung offengelegt?

Die Störung zeigte einige wiederkehrende Risiken verteilter Systeme auf:

• Single-Vendor-Abhängigkeit: Die Abhängigkeit von einem Anbieter für zentrale Infrastruktur kann große Auswirkungen haben.
• Fail-closed ohne Fallback: Security-first-Systeme brauchen Wege für Graceful Degradation, um vollständigen Lockout zu vermeiden.
• Unvollständige Migrationen: Laufende Architektur-Umstellungen können Lücken in der Ausfallsicherheit aufdecken.
• Cache-Recovery-Belastung: Unkontrollierte Neustarts von Caches können Systeme bei der Wiederherstellung überlasten.

Kurzfassung

Am 12. Juni 2025 gab es bei Cloudflare eine 2,5-stündige globale Störung, ausgelöst durch den Ausfall eines Drittanbieter-Speicher-Backends für Workers KV. Der Incident beeinträchtigte zentrale Dienste wie Access, WARP, Workers AI und Stream  teilweise mit 100 % Ausfall. Cloudflare reagierte mit schneller Eskalation, Gegenmaßnahmen und transparenter Kommunikation. Die Störung zeigte wichtige Resilienz-Risiken für Cloud-Architekturen auf, darunter Single-Vendor-Abhängigkeit und Fail-closed-Design.