OpenAI: Regionaler Ausfall des Identity-Systems beeinträchtigt ChatGPT und Codex

Unternehmen und Produkt

OpenAI entwickelt Systeme und Produkte im Bereich der künstlichen Intelligenz. Zu den bekanntesten Produkten gehören ChatGPT und Codex.

‍

ChatGPT bietet dialogbasierte und agentenbasierte Funktionen für Web, Mobile, Voice, Dateien und verbundene Services. Codex unterstützt Aufgaben in der Softwareentwicklung über verschiedene Repositories und Entwicklungsumgebungen hinweg.

‍

Beide Produkte greifen auf eine gemeinsame Backend-Infrastruktur zurück, darunter Identity- und Authentifizierungsdienste, Account Management, Storage, Caching und regionale Datenbank-Services. Ein Kapazitätsengpass bei einer gemeinsam genutzten Abhängigkeit kann daher mehrere kundenrelevante Funktionen gleichzeitig beeinträchtigen. 

Was war passiert?

Während Wartungsarbeiten an der Cloud-Infrastruktur fiel eine regionale Datenbankreplik aus, die den internen Identity Service von OpenAI unterstützte.

Datenbankrepliken sorgen normalerweise für Redundanz und zusätzliche Verarbeitungskapazität. Bei diesem Incident reichten die verbleibenden Kapazitäten in der Region jedoch nicht aus, um die gesamte Last zu bewältigen.

‍

Anfragen an den Identity Service wurden langsamer oder schlugen fehl. Dadurch verloren interne Caches an Effektivität und mehr Anfragen erreichten die bereits ausgelasteten Backend-Systeme.

Ablauf des Incidents:

• Einer regionale Datenbankreplik fällt aus.
• Die verbleibenden Kapazitäten reichten für die Last nicht aus.
• Anfragen an den Identity Service wurden langsamer oder schlugen fehl.
• Die Effektivität der Caches nahm ab.
• Abhängige Services erzeugten zusätzlichen Backend-Traffic.
• Die regionale Infrastruktur wurde zunehmend überlastet.
• Schutzmechanismen begannen, Anfragen abzulehnen.

OpenAI verfügte über Failover-Mechanismen, die den Traffic von beeinträchtigter regionaler Infrastruktur weglenken sollten. Sie leiteten jedoch nicht automatisch genügend Traffic in andere Regionen um.

‍

Da der Identity Service mehrere Produkte und Funktionen unterstützte, beschränkten sich die Auswirkungen nicht auf Unterhaltungen. Auch Voice, Work Mode, Connectors, Dateien, die Library-Funktion sowie einige Codex-Anfragen waren betroffen.

Timeline

• Vor 07:08 Uhr PDT — genaue Uhrzeit nicht veröffentlicht: Während Wartungsarbeiten an der Cloud-Infrastruktur fällt eine regionale Datenbankreplik des Identity Service aus.
• 07:08 Uhr PDT: Erste Auswirkungen auf Nutzer. Bei einem Teil der Nutzer treten Fehler bei Unterhaltungen und damit verbundenen Funktionen auf.
• Während der Untersuchung: Engineers stellen fest, dass die verbleibende regionale Datenbankkapazität die Last nicht bewältigen kann.
• Während des Incidents: Datenbankfehler reduzieren die Effektivität der Caches und erhöhen den Backend-Traffic.
• Während des Incidents: Das automatische Failover leitet nicht genügend Traffic aus der betroffenen Region um.
• Während des Incidents: Schutzmechanismen beginnen, Anfragen abzulehnen, um eine weitere Überlastung zu begrenzen.
• 07:46 Uhr PDT: Engineers beginnen, den Traffic manuell auf verfügbare Kapazitäten in anderen Regionen umzuleiten.
• Nach 07:46 Uhr PDT: Die regionale Last geht zurück und die Wiederherstellung beginnt.
• Während der Wiederherstellung: Der Cloud-Provider setzt weitere Wartungsarbeiten aus, während die Stabilität überprüft wird.
• 08:05 Uhr PDT: OpenAI bestätigt, dass die betroffenen Services vollständig wiederhergestellt sind.

Time to Detect (TTD): Nicht öffentlich bekannt gegeben.

Time to Resolve (TTR): Etwa 57 Minuten vom Beginn der Auswirkungen auf Nutzer um 07:08 Uhr PDT bis zur Wiederherstellung um 08:05 Uhr PDT.

Wer war betroffen?

• Ein Teil der ChatGPT-Nutzer. Sie konnten Unterhaltungen nicht laden oder fortsetzen.
• Nutzer von ChatGPT Voice und Work Mode.
• Nutzer, die auf Connectors, Dateien und die Library-Funktion zugriffen.
• Nutzer, deren Codex-Anfragen während des Incidents fehlschlugen.

OpenAI stufte den Incident als Teilausfall und nicht als vollständigen Ausfall der Plattform ein.

‍

Die veröffentlichten Verfügbarkeitsmetriken werden über verschiedene Abonnementstufen, Modelle und Fehlertypen hinweg aggregiert. Die individuelle Verfügbarkeit kann je nach Abonnementstufe, verwendetem Modell und genutzten API-Funktionen variieren.

Wie reagierte OpenAI?

OpenAI führte die erhöhte Fehlerrate auf unzureichende Datenbankkapazitäten nach dem Ausfall der regionalen Replik zurück.

‍

Um 07:46 Uhr PDT leiteten Engineers Anfragen manuell aus der betroffenen Region auf verfügbare Kapazitäten in anderen Regionen um. Dadurch sank die Belastung der Datenbank und der Identity Service – die Caches sowie abhängige Systeme konnten sich stabilisieren.

‍

Der Cloud-Provider setzte weitere Wartungsarbeiten aus, während OpenAI die Wiederherstellung überprüfte und eine Neuverteilung der Kapazitäten plante.

OpenAI identifizierte drei zentrale Bereiche, um ähnliche Incidents zukünftig zu vermeiden:

• Verbesserung der regionalen Kapazitätsplanung und Sicherstellung, dass Services den Ausfall einer Datenbankreplik verkraften können.
• Verbesserung des automatischen Failovers und der regionenübergreifenden Umleitung von Traffic.
• Robustere Gestaltung der Retry-Mechanismen und Circuit Breaker durch erweiterte Fehlertests und Überprüfung der Systemtopologie.

Wie kommunizierte OpenAI?

OpenAI informierte über seine öffentliche Statusseite.

‍

In den ersten Updates hieß es, dass bei einigen Nutzern Fehler beim Laden oder Fortsetzen von Unterhaltungen auftraten. Spätere Updates wiesen auf zusätzliche Beeinträchtigungen bei Voice und Work Mode hin und informierten über laufende Maßnahmen zur Behebung.

‍

OpenAI setzte den Incident zunächst auf Monitoring, bevor die vollständige Wiederherstellung bestätigt wurde. Später veröffentlichte das Unternehmen einen ausführlichen Bericht zu den Auswirkungen, der Root Cause, den ergriffenen Maßnahmen und den geplanten Verbesserungen.

Wichtige Erkenntnisse für andere Teams

• Ausfall einer Replik unter Last testen: Die verbleibende Infrastruktur muss nachweislich in der Lage sein, die gesamte Produktionslast zu tragen.
• Kapazitätsreserven vorhalten: Regionen, die nahe an ihrer Kapazitätsgrenze betrieben werden, können Wartungsarbeiten oder den Ausfall einzelner Komponenten möglicherweise nicht abfangen.
• Regionales Failover automatisieren: Eine Multi-Region-Architektur bietet nur begrenzten Schutz, wenn Traffic manuell umgeleitet werden muss.
• Nachlassende Cache-Leistung überwachen: Sinkende Hit Rates können zusätzlichen Traffic an ein bereits überlastetes Backend weiterleiten.
• Lastabhängige Retries einsetzen: Backoff, Retry Budgets, Circuit Breaker und Load Shedding sollten zusammenwirken.
• Wartungsarbeiten wie Ausfallszenarien testen: Geplante Arbeiten können Kapazitäten ebenso stark reduzieren wie ein unerwarteter Fehler.
• Aktuelle Topologie überprüfen: Die tatsächliche Platzierung der Repliken und die verfügbaren Kapazitäten sollten validiert werden, anstatt sich ausschließlich auf Architekturdiagramme zu verlassen.
• Identity Services schützen: Gemeinsam genutzte Authentifizierungs- und Identity-Abhängigkeiten können weitreichende Auswirkungen haben.

Zusammenfassung 

Am 19. Juli 2026 kam es bei OpenAI zu einem Teilausfall, der ChatGPT-Unterhaltungen, Codex-Anfragen, Voice, Work Mode, Connectors, Dateien und die Library-Funktion beeinträchtigte. Während Wartungsarbeiten an der Cloud-Infrastruktur fiel eine regionale Datenbankreplik aus, die einen internen Identity Service unterstützte. Die verbleibenden Kapazitäten konnten die gesamte Last nicht bewältigen, wodurch Datenbankfehler auftraten, die Effektivität der Caches sank und die Belastung der Backend-Systeme zunahm. Das automatische Failover leitete nicht genügend Traffic um, sodass Schutzmechanismen begannen, Anfragen abzulehnen. Um 07:46 Uhr PDT leiteten Engineers den Traffic manuell um; um 08:05 Uhr PDT war der Service vollständig wiederhergestellt. Der Incident zeigte, dass Redundanz nur dann wirksam ist, wenn die verbleibenden Kapazitäten zuvor unter voller Produktionslast getestet wurden.

So kann ilert helfen

Ausfälle gemeinsam genutzter Infrastruktur können gleichzeitig Alarmierungen über zahlreiche Produkte hinweg auslösen.

• Alarmierung bei Kapazitätsrisiken: Metriken zum Zustand von Repliken, zu Identity-Fehlern, zur regionalen Auslastung, zu Cache Hit Rates und zu abgelehnten Anfragen können direkt an ilert weitergeleitet werden.
• Gruppierung von zusammengehörigen Alarmierungen: Signale aus Unterhaltungen, Voice, Dateien, Connectors und Codex können in ilert zusammengeführt werden.
• Automatisierte Eskalation: Benachrichtigung von Datenbank-, Identity-, SRE- und Plattform-Teams über mehrstufige Eskalationsrichtlinien.
• Failover-Koordination: Über den Incident-Management-Workspace von ilert lassen sich ein dedizierter Incident-Kanal einrichten, Responder zuweisen, die Umleitung des Traffics koordinieren und die Wiederherstellung von Datenbank und Cache verfolgen.
• Gezielte Kommunikation: Klare Unterscheidung zwischen den betroffenen Funktionen und den weiterhin verfügbaren Services über die ilert Statusseiten.
• Unterstützung von Postmortems: Analysen auf Basis des Alarmierungsverlaufs, der Aktivitäten der Responder, der Status-Updates und der Timeline-Events.