Als Facebook ausfiel, half auch WhatsApp nicht weiter

Zusammenfassung

• Ein Wartungsbefehl trennte Verbindungen zwischen Rechenzentren. Danach war auch die Auskunft über die Internetadressen der Dienste nicht mehr erreichbar, obwohl ihre Server weiterliefen.
• Die Reparatur brauchte wiederhergestellte Zugänge und einen vorsichtigen Neustart. Aus externen Zeitmarken lässt sich weder eine Anfahrtsdauer noch eine einheitliche Ausfallzeit aller Dienste ablesen.

Die Seite neu laden, die App schließen, die App wieder öffnen: So beschreibt Cloudflare die Reaktion auf Facebooks Ausfall am 4. Oktober 2021. Auch die Apps versuchten es automatisch erneut. Für die Nutzer änderte das nichts am entscheidenden Problem: Der Dienst, über den sie andere Menschen erreichen wollten, blieb unerreichbar.

Und WhatsApp? Ebenfalls betroffen. Instagram auch. Drei vertraute Namen auf dem Handy boten in diesem Moment keinen Ausweg. Cloudflare verzeichnete mehr DNS-Anfragen nach Twitter, Signal und anderen Kommunikationsplattformen. Das zählt keine neu gewonnenen Nutzer und verrät nicht, welche Nachricht schließlich ankam. Es zeigt die Suche nach anderen erreichbaren Diensten.

Während Nutzer anderswo nach Verbindung suchten, verloren Facebooks Techniker ihre eigenen Zugänge: den normalen Netzwerkzugang ebenso wie den gesonderten Verwaltungszugang. Sie konnten nicht einfach von außen den Fehler beheben. Zuerst mussten sie wieder an ihre Systeme herankommen.

Die Helfer mussten selbst erst hinein

Facebook schickte Ingenieure vor Ort. Dort trafen sie auf Vorkehrungen, die normalerweise gerade verhindern sollten, dass jemand schnell Zugang bekommt oder Geräte verändert. Physische und technische Sicherheitsmaßnahmen verlangsamten nun die Reparatur. So beschreibt es Facebooks eigener Bericht. Er nennt keine gemessene Anfahrtsdauer. Dass Menschen vor Ort gebraucht wurden, ist belegt; wie lange sie unterwegs waren, nicht.

Der Anlass war keine geplante Abschaltung. Bei einer Routinewartung sollte ein Befehl die Kapazität des Netzes zwischen den Rechenzentren prüfen, des sogenannten Backbone. Stattdessen kappte er unbeabsichtigt Verbindungen. Ein Prüfwerkzeug hätte die Ausführung stoppen sollen. Ein Fehler darin verhinderte das.

Damit standen die Techniker vor mehr als einem unterbrochenen Netz. Auch Werkzeuge zur Untersuchung des Fehlers fielen aus, weil sie DNS brauchten, die Adressauskunft des Internets. Der Bericht trennt diese Werkzeugausfälle vom Verlust der Verwaltungszugänge. Er belegt nicht, dass DNS gerade den gesonderten Zugang lahmgelegt hatte.

Auch die Adressauskunft braucht einen Weg

Wer facebook.com aufruft, verwendet einen Namen. Das Gerät braucht dazu eine Internetadresse. DNS liefert diese Auskunft — sofern die Anfrage beim zuständigen Server ankommt. Bei Facebook liefen die DNS-Server zwar noch. Sie hatten aber ihre Verbindung zu den Rechenzentren verloren.

Für diesen Fall zog Facebook automatisch die Wegweiser zu diesen Servern zurück. Diese Wegweiser heißen BGP-Ankündigungen: Sie sagen anderen Netzen, wie ein Ziel erreichbar ist. Ohne sie fanden Anfragen nicht mehr zur Auskunft. Darum half es nicht, die App immer wieder zu öffnen. Die Antwort blieb aus, obwohl die Server eingeschaltet waren.

Auch für die Ingenieure machte das einen Unterschied. Ein Neustart laufender Server konnte fehlende Verbindungen nicht ersetzen. Der Weg zu den Systemen musste wieder funktionieren. Erst dann konnte aus der Reparatur eine Rückkehr für die Nutzer werden.

Nicht alles auf einmal einschalten

Als das Netz zwischen den Rechenzentren wieder verbunden war, durfte Facebook nicht gleich den nächsten Ausfall provozieren. Ein gleichzeitiger Neustart konnte Spitzen bei Datenverkehr und Strombedarf auslösen. Die Wiederkehr musste deshalb vorsichtig erfolgen — eine weitere Etappe, obwohl die Verbindungen schon zurück waren. Frühere Störungsübungen halfen dabei. Den vollständigen Verlust des weltweiten Backbone hatte das Unternehmen jedoch nicht geprobt.

Von außen wurde dieser Rückweg allmählich sichtbar. Cloudflare sah gegen 21 Uhr UTC wieder BGP-Aktivität, mit einer Spitze um 21:17 Uhr. Um 21:28 Uhr schienen die weltweite Wiederanbindung und DNS zurück. Manche Anwendungen konnten länger brauchen. Für Nutzer war die entscheidende Frage nicht, ob ein Netz wieder etwas ankündigte, sondern ob der eigene Dienst schon funktionierte.

Diese Uhrzeiten sind kein Protokoll der Ingenieure. Cloudflare hatte um 15:40 Uhr viele Routingänderungen beobachtet und um 15:58 Uhr den Rückzug der Routen zu Facebooks DNS-Adressbereichen. Andere Adressbereiche blieben im Routing. Die 18 Minuten dazwischen belegen keine interne Warnfrist; die 330 Minuten von 15:58 bis 21:28 Uhr weder eine Anreise noch die Ausfalldauer für jeden Nutzer. Die Messungen zeigen auch nicht den fehlerhaften Befehl oder die interne Alarmfolge.

Derweil arbeitete das übrige Internet weiter. Bei Cloudflares Adressauskunft 1.1.1.1 sorgten die wiederholten Versuche für zusätzliche Last. Die langsamsten Antworten wurden langsamer, die meisten Anfragen dauerten aber weiterhin weniger als zehn Millisekunden. Es gab erreichbare Alternativen, nur eben nicht bei jedem Wechsel zu einer anderen App.

Am Ende mussten zwei Seiten wieder zusammenfinden: Menschen, die ihre Dienste nutzen wollten, und Techniker, die erst den Zugang zurückgewannen und dann vorsichtig den Betrieb hochfuhren. Darin liegt die eigentliche Schwierigkeit dieses Ausfalls. Reparieren setzt voraus, dass die Helfer handeln können. Die beiden Berichte erklären, warum das 2021 nicht selbstverständlich war; wie Meta Platforms heute aufgebaut ist oder welche späteren Änderungen umgesetzt wurden, belegen sie nicht.

Korrektur vom 21. Oktober 2026: Verwaltungszugänge und DNS-abhängige Werkzeuge werden getrennt behandelt. Externe Zeitmarken gelten nicht mehr als Beleg für Anfahrtszeiten oder eine überall gleiche Ausfalldauer. Unbelegte Aussagen über die heutige Architektur wurden entfernt.