ChatGPT und Claude fielen zugleich aus – ein zweiter Anbieter genügt nicht

ChatGPT und Claude fielen am 3. September 2026 zeitlich überlappend für einen Teil der Nutzer aus. OpenAI und Anthropic dokumentierten erhöhte Fehlerraten und behoben ihre jeweiligen Störungen noch am selben Tag; der Bericht von WIRED bestätigt die zeitliche Nähe, aber keine gemeinsame Ursache.
Die akuten Störungen sind beendet. Für Unternehmen bleibt die betriebliche Konsequenz: Ein zweiter KI-Anbieter ist noch keine belastbare Ausweichlösung, wenn beide Zugangswege von denselben Cloud-Komponenten, Identitätsdiensten, internen Anwendungen oder KI-gestützten Arbeitsschritten abhängen.
Die Störungsfenster überschnitten sich

OpenAI untersuchte ab 14:43 UTC erhöhte Fehler bei ChatGPT und Codex, setzte um 15:17 UTC eine Gegenmaßnahme ein und markierte den Vorfall um 16:55 UTC als behoben. Der OpenAI-Incident-Eintrag nennt ChatGPT und Codex als betroffene Komponenten und weist darauf hin, dass einzelne Nutzer der Codex-Fernsteuerung ihr Mobilgerät anschließend erneut koppeln mussten.
Anthropic begann um 13:26 UTC mit der Untersuchung erhöhter Fehler bei mehreren Claude-Modellen. Der Claude-Incident-Eintrag nennt Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8 und Opus 4.6 und führt claude.ai, die Claude API, Claude Code und Claude Cowork als betroffene Dienste auf; die Auswirkungen endeten demnach um 16:16 UTC.
Damit liefen beide Vorfälle zwischen 14:43 und 16:16 UTC parallel. Die Einträge belegen jedoch weder, dass alle Nutzer vollständig ausgesperrt waren, noch dass beide Ausfälle denselben technischen Ursprung hatten. OpenAI führte seinen Vorfall später auf einen Routingfehler zurück; Anthropic erklärte lediglich, die Ursache identifiziert zu haben, veröffentlichte in seinem Incident-Eintrag aber keine technischen Einzelheiten.
Warum der zweite Anbieter allein nicht genügt
Redundanz entsteht nicht schon durch zwei Verträge oder API-Schlüssel. Entscheidend ist der vollständige Ausführungspfad: Laufen ChatGPT und Claude über dasselbe API-Gateway, dieselbe Identitätsplattform, denselben Cloud-Account oder dieselbe interne Oberfläche, kann eine gemeinsame Komponente beide Wege gleichzeitig blockieren.
Hinzu kommen organisatorische Abhängigkeiten. Ein erreichbarer Ersatzdienst hilft wenig, wenn für ihn keine freigegebenen Aufgaben, Datenklassen, Prompt-Vorlagen und Prüfregeln festgelegt sind. Beschäftigte dürfen dann möglicherweise nicht dieselben Inhalte übertragen oder können Ergebnisse nicht in das erwartete Format zurückführen.
Die Überschneidung vom 3. September beweist keinen gemeinsamen Infrastrukturfehler. Sie zeigt aber das relevante Betriebsszenario: Zwei voneinander getrennte Anbieter können im selben Zeitfenster unbenutzbar sein. Ein Ausfallplan muss deshalb nicht nur einzelne Ursachen, sondern auch das sichtbare Ergebnis eines korrelierten Ausfalls abdecken.
Der Ausfallplan braucht klare Schaltpunkte

Vor der nächsten Störung sollte feststehen, welche Signale einen Wechsel auslösen und wer ihn verantwortet. Eine einzelne Fehlermeldung reicht nicht, weil auch ein lokales Netzwerkproblem, abgelaufene Zugangsdaten oder ein Fehler in der eigenen Anwendung dahinterstehen können.
- Status abgleichen: Offizielle Statusmeldungen, eigene Telemetrie und einen direkten Minimalaufruf vergleichen. So lässt sich ein Anbieterproblem von einer internen Störung trennen.
- Circuit Breaker auslösen: Überschreitet die Fehlerrate einen intern definierten Grenzwert, werden automatische Wiederholungen begrenzt. Anwendungen bleiben dadurch nicht in langen Time-outs hängen und verstärken die Störung nicht durch zusätzliche Anfragen.
- Aufträge puffern: Nicht zeitkritische Aufgaben werden mit Priorität, Zeitstempel und Wiederholungsgrenze in einer Queue gehalten. Vertrauliche Inhalte dürfen dabei nicht ungeprüft in weitere Systeme kopiert werden.
- Ersatzanbieter kontrolliert aktivieren: Nur zuvor freigegebene Aufgaben wechseln automatisch. Modellbezeichnungen, Kontextgrenzen, Ausgabeformate und Sicherheitsmechanismen sind nicht ohne Prüfung austauschbar.
- Nicht KI-basierten Ersatz öffnen: Kritische Tätigkeiten müssen notfalls mit lokalen Vorlagen, Regelwerken, klassischen Suchfunktionen oder menschlicher Bearbeitung weiterlaufen.
Nach der Wiederherstellung sollten wartende Aufträge gestaffelt statt gleichzeitig erneut gesendet werden. Deduplizierung, begrenzte Wiederholungen und eine kontrollierte Rückkehr zum Hauptanbieter verhindern doppelte Verarbeitung und eine neue Lastspitze.
Gemeinsame Abhängigkeiten müssen im Test sichtbar werden

Eine belastbare Abhängigkeitskarte endet nicht bei OpenAI und Anthropic. Sie umfasst auch DNS, Netzwerkzugänge, Cloud-Regionen, Identitätsdienste, API-Gateways, Secret-Verwaltung, Datenbanken, Monitoring und die interne Anwendung, über die Beschäftigte auf die Modelle zugreifen.
Für wichtige Abläufe braucht es zudem portable Betriebsdaten. Das müssen nicht vollständige Chatverläufe sein; häufig genügen aktuelle Prompt-Vorlagen, Regeln, offene Aufträge, zulässige Datenklassen und Prüfkriterien in einem dokumentierten Format. Ohne diese Grundlage kann ein technisch verfügbarer Ersatzanbieter den Prozess nicht kurzfristig übernehmen.
Ausfalltests sollten mindestens vier getrennte Szenarien abbilden: nur ChatGPT gestört, nur Claude gestört, beide Anbieter gleichzeitig beeinträchtigt und eine gemeinsam genutzte Komponente nicht erreichbar. Geprüft werden müssen Erkennung, Umschaltung, Queueing, Berechtigungen und Rückkehr in den Normalbetrieb – nicht lediglich das Architekturdiagramm.
Behoben sind die Vorfälle, nicht das Redundanzproblem
Beide Anbieter haben ihre Störungen vom 3. September als behoben markiert. Öffentlich belegt sind die zeitliche Überschneidung, die betroffenen Produktbereiche und die getrennte Wiederherstellung; nicht belegt ist ein gemeinsamer technischer Auslöser.
Für die Ausfallvorsorge ist diese offene Ursachenfrage zweitrangig. Belastbare Redundanz verlangt unabhängige Statussignale, begrenzte Wiederholungen, eine kontrollierte Warteschlange, portable Betriebsdaten und einen ausdrücklich nicht KI-basierten Ersatzprozess. Erst wenn dieser gesamte Pfad getestet ist, wird aus einem zweiten Anbieter eine tatsächlich nutzbare Reserve.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.