ChatGPT, Claude und Grok: Was hinter den Ausfällen vom 3. September steckt

Mehrere führende KI-Dienste waren am 3. September 2026 innerhalb weniger Stunden gestört: OpenAIs ChatGPT und Codex, Anthropics Claude-Angebote sowie xAIs Grok. Die zeitliche Überschneidung war real. Die belastbarste Schlussfolgerung lautet aber nicht, dass „das KI-Internet“ mit einer einzigen Ursache ausgefallen sei: Die öffentlich bekannten Angaben beschreiben getrennte Vorfälle mit unterschiedlichen genannten Ursachen. Ein gemeinsamer Auslöser ist nicht belegt. 334148

Was wann ausfiel

Die Zeitangaben sind nicht völlig deckungsgleich, weil Statusseiten und Medienupdates unterschiedliche Zeitpunkte erfassen. Sie erklären aber, warum Nutzerinnen und Nutzer die Störungen als nahezu gleichzeitig wahrnahmen.

• Grok: Der dokumentierte Vorfall bei xAI begann Berichten zufolge um 13:30 UTC und endete um 17:05 UTC. Später führte xAI die Störung auf einen Ausfall im eigenen Rechenzentrum in Memphis zurück. 48
• Claude: Anthropic meldete erhöhte Fehlerraten bei mehreren Claude-Modellen und Produkten – darunter Claude.ai, die API, Claude Code und Claude Cowork. Die Störung war bis 16:16 UTC behoben und dauerte rund drei Stunden. 104148
• ChatGPT und Codex: OpenAI zufolge machte ein interner Routingfehler ab 07:43 Uhr pazifischer Zeit ChatGPT und Codex für einen Teil der Nutzerschaft plattformübergreifend nicht verfügbar. Gegen 08:17 Uhr sei eine Lösung umgesetzt worden, deren Wirkung anschließend überwacht wurde. 41

Gemeldet wurden unter anderem Anmeldeprobleme, nicht verfügbare Chats, fehlgeschlagene Prompts sowie Schwierigkeiten in Apps und im Web. Downdetector-basierte Berichte zählten bei ChatGPT gegen 20 Uhr indischer Zeit mehr als 43.000 Störungsmeldungen. Bei Claude waren sowohl Endnutzerprodukte als auch Werkzeuge für Entwickler betroffen. 2339

Welche Ursachen die Anbieter nannten

Die veröffentlichten Erklärungen sind entscheidend: Sie stützen nicht die Behauptung eines bereits bestätigten gemeinsamen Ausfalls.

OpenAI: Ein Unternehmenssprecher bezeichnete die Störung bei ChatGPT und Codex als Routingfehler innerhalb der OpenAI-Infrastruktur. 41

Anthropic: Die öffentlichen Statusmeldungen beschrieben das Claude-Problem als Infrastrukturstörung und bestätigten erhöhte Fehlerraten über mehrere Modelle und Dienste hinweg. Welcher konkrete technische Bestandteil ausfiel, wurde in den vorliegenden Informationen nicht genannt. 3948

xAI: Nachträgliche Berichte verknüpften den Grok-Ausfall mit dem Rechenzentrum von xAI in Memphis. Das Unternehmen entschuldigte sich bei betroffenen Compute-Partnern. 48

Diese Angaben schließen gemeinsame Abhängigkeiten nicht grundsätzlich aus. Sie belegen sie aber auch nicht.

War Microsoft Azure oder ein anderer gemeinsamer Dienstleister verantwortlich?

Dafür gibt es auf Basis der vorliegenden öffentlichen Informationen keinen bestätigten Nachweis. Weder Microsoft Azure noch ein Netzbetreiber, ein Content-Delivery-Netzwerk (CDN), ein Identitätsdienst oder ein anderer Zulieferer wurde öffentlich als Ursache aller Störungen bestätigt.

Zeitgenössische Berichte nannten Azure als möglichen Ansatzpunkt, weil Microsoft Cloud-Dienste für die beteiligten Unternehmen bereitstellt. Das ist jedoch kein Kausalitätsnachweis. 42 Zeitlich parallele Probleme können auch unabhängig voneinander auftreten – besonders, wenn Ausfälle über Nutzermeldungen statt über einen gemeinsamen technischen Incident-Bericht sichtbar werden.

Das sachliche Fazit lautet daher: Eine gemeinsame Infrastrukturursache ist unbestätigt. Aussagen, wonach ein regionaler Azure-Ausfall alle Vorfälle ausgelöst habe, sollten ohne direkte Bestätigung der Anbieter oder einen technischen Abschlussbericht nicht als Tatsache gelten.

Erklärt Anthropics angeblicher Zugang zu Colossus 1 den Claude-Ausfall?

Die vorliegenden Berichte reichen nicht aus, um Umfang und Bedeutung eines möglichen Anthropic-Zugangs zur Colossus-1-Anlage von xAI/SpaceXAI zu belegen. Ebenso wenig lässt sich daraus ableiten, dass Claudes Produktionsbetrieb während dieses Vorfalls von dieser Kapazität abhängig war. Ein gemeldeter Ausfall in Memphis, der Grok betraf, beweist nicht, dass dadurch auch Claude gestört wurde. 48

Für die Bewertung von Ausfallsicherheit ist diese Trennung wichtig: Selbst eine nachgewiesene kommerzielle Vereinbarung über Rechenkapazität wäre noch kein Beleg dafür, dass ein bestimmter nutzerseitiger Dienst genau in diesem Moment auf dieser Infrastruktur lief.

Was über die erneuten ChatGPT-Meldungen aus Indien am 7. September bekannt war

Am 7. September berichteten einige Nutzerinnen und Nutzer erneut über Probleme mit ChatGPT. Im Mittelpunkt stand dabei die Inhaltsgenerierung; außerdem wurden Schwierigkeiten im Browser und in der App gemeldet. Ein Bericht verzeichnete rund 261 Nutzermeldungen, wobei die Erstellung von Inhalten den größten Anteil der Beschwerden ausmachte. 19

Damit war jedoch weder ein anhaltender landesweiter Ausfall in Indien noch eine bestätigte technische Ursache oder ein Zusammenhang mit dem 3. September nachgewiesen. Ein externer Monitor erreichte ChatGPT am selben Tag um 03:07 UTC ohne ungewöhnliche Fehler oder Antwortzeiten. Das passt eher zu einer teilweisen, intermittierenden oder regional unterschiedlich ausgeprägten Störung als zu einem durchgehenden landesweiten Ausfall. 22

Die Lehre für Unternehmen: Mehrere KI-Anbieter bedeuten nicht automatisch Ausfallsicherheit

Die Störungen vom 3. September zeigen, wie rasch KI-abhängige Arbeitsabläufe unterbrochen werden können – etwa im Kundenservice, in der Softwareentwicklung, Recherche, Dokumentenverarbeitung oder bei agentischen Workflows.

Mehrere KI-Abonnements helfen gegen den Ausfall eines einzelnen Anbieters. Sie garantieren aber keine Betriebsfähigkeit, wenn Systeme gemeinsame Infrastruktur- oder Zugangsschichten nutzen oder wenn Arbeitsabläufe vom selben Browser, Identitätsdienst, Netzwerk oder einer gemeinsamen Integration abhängen.

Für robustere KI-Workflows sind vor allem diese Vorkehrungen sinnvoll:

• Manuelle Alternativen und persistente Warteschlangen: Kritische Aufträge sollten nach Fehlern wiederaufgenommen werden können, statt verlorenzugehen.
• Failover zwischen Anbietern: Geeignete Aufgaben können an ein anderes Modell weitergeleitet werden – mit dem Bewusstsein, dass korrelierte Ausfälle dennoch möglich sind.
• Robuste API-Fehlerbehandlung: Begrenzte Timeouts, Wiederholungen mit wachsendem Abstand, Circuit Breaker und idempotente Jobs verhindern, dass eine kurze Störung doppelte Arbeit auslöst.
• Ein definierter Degradationsmodus: Vorab festlegen, was ohne Frontier-Modell weiterläuft, etwa regelbasierte Weiterleitung, zwischengespeicherte Antworten, verzögerte Bearbeitung oder menschliche Prüfung.
• Unabhängiges Monitoring und Incident-Protokolle: Statusseiten der Anbieter sollten neben eigenen synthetischen Tests beobachtet werden. Protokolle sollten erfassen, welcher Anbieter, welches Modell und welche Integration betroffen waren.

Die zentrale Erkenntnis ist nicht, dass jeder gleichzeitige Ausfall zwangsläufig eine verborgene gemeinsame Ursache haben muss. Unternehmen sollten diese Möglichkeit aber einplanen – und ihre Ausweichkonzepte testen, bevor die nächste Störung eintritt.