ChatGPT, Claude und Grok: Was hinter den Ausfällen am 3. September 2026 steckte

Drei große KI-Dienste waren am 3. September 2026 zeitgleich beziehungsweise überlappend gestört. Die öffentliche Faktenlage belegt jedoch keinen gemeinsamen Auslöser für alle drei: Der Betreiber von Grok führte den eigenen Ausfall auf ein Rechenzentrum in Memphis zurück. OpenAI nannte für ChatGPT und Codex dagegen einen separaten Routingfehler. Anthropic sprach bei Claude lediglich von einem Infrastrukturproblem. 3540

Was als gesichert gilt

Der Betreiber von Grok erklärte, ein Ausfall im Compute-Center in Memphis habe Probleme bei Grok verursacht, und entschuldigte sich zugleich bei betroffenen „Compute-Partnern“. Berichten zufolge begann die Grok-Störung gegen 6:30 Uhr pazifischer Zeit und dauerte etwa dreieinhalb Stunden. 40

OpenAI nannte für ChatGPT und Codex eine andere Ursache: Ein Routingfehler begann gegen 7:43 Uhr pazifischer Zeit und machte die Dienste für einen Teil der Nutzerinnen und Nutzer plattformübergreifend unzugänglich. Gegen 8:17 Uhr sei eine Lösung umgesetzt worden. 35

Auch bei Claude stiegen die Fehlerraten. Die damals veröffentlichte Statusinformation weist einen Vorfall von drei Stunden und sechs Minuten aus; Anthropic bezeichnete ihn als Infrastrukturproblem bei Claude-Diensten. Welcher Bestandteil betroffen war, wurde öffentlich nicht genannt. Ebenso gibt es keinen öffentlichen Nachweis, dass Claude im Memphis-Standort betrieben wurde oder von ihm abhängig war. 3545

Der entscheidende Unterschied lautet daher: Der Fehler im Memphis-Rechenzentrum ist für Grok bestätigt. Für ChatGPT und Codex ist ein separater Routingfehler dokumentiert. Ein Memphis-Zusammenhang bei Claude bleibt eine unbelegte Schlussfolgerung.

Zeitgleich heißt nicht: identischer Ausfall

Oft ist von einem simultanen oder fünfstündigen KI-Ausfall die Rede. Als Kurzbeschreibung für das Zeitfenster, in dem mehrere führende Dienste Probleme hatten, ist das verständlich. Es bedeutet aber nicht, dass jeder Anbieter fünf Stunden lang vollständig ausgefallen war.

Nach den verfügbaren Berichten traten bei Claude gegen 6:23 Uhr pazifischer Zeit erstmals erhöhte Fehlerraten auf, bei Grok etwa um 6:30 Uhr und bei ChatGPT um 7:43 Uhr. Claude war gegen 9:16 Uhr wiederhergestellt; Grok war den Berichten zufolge etwa dreieinhalb Stunden beeinträchtigt. 354045

Praktisch war die Überschneidung dennoch relevant: Betroffen sein konnten Chat-Anwendungen für Endkunden, Modell-APIs, Programmierwerkzeuge und KI-gestützte Arbeitsabläufe. Die übliche Ausweichstrategie – Aufgaben einfach zu einem anderen großen Modellanbieter zu verlagern – funktionierte während der gemeinsamen Störungsphase deutlich schlechter. 3538

War Claude vom Memphis-Ausfall betroffen?

Es gibt einen nachvollziehbaren Grund, warum diese These aufkam: Der Grok-Betreiber erklärte, das Ereignis in Memphis habe auch nicht näher benannte Compute-Partner betroffen. Zeitgleich hatte Claude einen Infrastrukturvorfall. 4045

Plausibilität ist jedoch kein Beleg. In den vorliegenden Berichten nannte der Betreiber weder Anthropic noch Claude als betroffenen Partner. Anthropic wiederum benannte Memphis nicht als Ursache. Daraus folgt:

• Bestätigt: Grok war vom Ausfall des Compute-Centers in Memphis betroffen. 40
• Bestätigt: Claude hatte eine infrastrukturbedingte Störung. 3545
• Nicht bestätigt: Claudes Störung wurde durch den Standort Memphis verursacht oder lief über dessen Infrastruktur.

Aus der zeitlichen Nähe eine Ursache-Wirkungs-Beziehung abzuleiten, würde mehr behaupten, als die öffentliche Beweislage hergibt.

Warum Azure und Cloudflare nicht endgültig ausgeschlossen werden können

Die öffentlichen Informationen erlauben auch nicht die Aussage, Azure oder Cloudflare seien definitiv „ausgeschlossen“ worden. Belegt ist nur, dass die veröffentlichten Erklärungen auf andere unmittelbare Ursachen verwiesen: OpenAI nannte einen Routingfehler, Groks Betreiber den Ausfall in Memphis. 3540

Keine der vorliegenden Quellen benennt einen breit angelegten Ausfall von Azure oder Cloudflare als Ursache. Das macht einen einzigen, providerweiten Fehler weniger wahrscheinlich. Indirekte Abhängigkeiten – etwa über regionale Netzverbindungen, DNS, Identitätsdienste, Transitwege, Kapazitätsengpässe oder gemeinsame Zulieferer – lassen sich ohne detaillierte Abhängigkeitsdaten und technische Postmortems aber nicht ausschließen.

Die zentrale Lehre: Mehrere Anbieter bedeuten nicht automatisch Unabhängigkeit

Der Vorfall zeigt, warum eine Liste verschiedener Modellanbieter allein noch kein belastbarer Notfallplan ist. Dienste, die für Kundinnen und Kunden unabhängig wirken, können gemeinsame Abhängigkeiten haben: physische Rechenkapazität, Regionen, Netzwerkwege, Authentifizierung, Modell-Hosting, Hardwarelieferketten oder Betriebsprozesse. Fällt eine dieser Ebenen aus, können mehrere vermeintliche Alternativen gleichzeitig nicht verfügbar sein.

Das Risiko wächst, sobald KI nicht nur für gelegentliche Chats, sondern in operative Prozesse eingebunden wird. Ein nicht verfügbares Modell kann Warteschlangen, Tool-Aufrufe, Freigaben, Kundenservice-Abläufe, Entwicklungs-Pipelines oder Monitoring blockieren. Beim Wiederanlauf entsteht ein zweites Risiko: Wiederholungsversuche könnten externe Aktionen doppelt auslösen oder den notwendigen Zustand für eine saubere Fortsetzung verlieren.

So sollten Unternehmen KI-Ausfälle testen

Organisationen, die KI produktiv einsetzen, sollten mindestens diese Szenarien erproben:

1. Vollständiger Anbieterausfall: Modell-APIs und Chat-Oberflächen sind nicht erreichbar.
2. Teilweise Verschlechterung: erhöhte Fehlerraten, hohe Latenzen, abgebrochene Streaming-Antworten oder nicht verfügbare Tools.
3. Authentifizierungs- und Netzwerkstörungen: Probleme bei Anmeldung, DNS, Routing oder regionalem Zugriff.
4. Korrelation mehrerer Anbieter: Zwei oder mehr vermeintlich unabhängige Anbieter fallen im selben Zeitfenster aus.
5. Risiken beim Wiederanlauf: Wiederholungen, Warteschlangen, Tool-Aufrufe und Freigaben müssen ohne doppelte Aktionen oder Zustandsverlust fortgesetzt werden können.

Solche Tests sollten Wiederherstellungszeit, Umgang mit Rückstau, menschliche Übernahme, Datenkonsistenz und Idempotenz messen – also ob eine Operation wiederholt werden kann, ohne unbeabsichtigt eine zweite Wirkung auszulösen.

Aussagekräftigere technische Postmortems der Anbieter würden die Bewertung erleichtern: Sie sollten Zeitachse, betroffene Komponenten und Regionen, Ursache, Gegenmaßnahmen sowie Schritte zur Vermeidung ähnlicher Vorfälle klar trennen. Für den 3. September reicht die öffentliche Datenlage aus, um Groks gemeldeten Memphis-Ausfall von OpenAIs Routingfehler zu unterscheiden. Sie reicht nicht aus, um eine gemeinsame Memphis-Abhängigkeit von Claude zu beweisen oder die tieferen Infrastrukturverflechtungen hinter der zeitlichen Überschneidung vollständig zu kartieren. 354045