Kurzantwort: mehrere Störungen, kein belegter globaler Totalausfall
OpenAI dokumentierte am 25. Juli drei getrennte Vorfälle. Zwei waren am Mittag behoben. Beim späteren Vorfall konnten einige Nutzer Unterhaltungen zeitweise nicht laden oder fortsetzen; eine Gegenmaßnahme wurde in der Nacht umgesetzt und die Wiederherstellung anschließend überwacht. Die offiziellen Meldungen sprechen von erhöhten beziehungsweise intermittierenden Fehlerraten – nicht davon, dass ChatGPT für jeden Nutzer weltweit vollständig ausgefallen war.
Bestätigte Fakten
Was am 25. Juli 2026 passiert ist
Die maschinenlesbare Incident-Historie von OpenAI enthält für den Tag drei relevante Einträge. Die folgenden Uhrzeiten sind aus UTC in mitteleuropäische Sommerzeit umgerechnet:
Erhöhte Fehlerraten bei API, ChatGPT und Codex
OpenAI führte 12 API-, 15 ChatGPT- und 4 Codex-Komponenten als betroffen. Nach einer Gegenmaßnahme meldete der Anbieter die Dienste als vollständig wiederhergestellt. Zum ersten offiziellen Incident (öffnet in neuem Tab)
Zweiter Incident mit denselben Komponentengruppen
Nur rund 27 Minuten später wurde ein weiterer Anstieg der Fehlerraten erfasst. Nach etwa 22 Minuten galt auch dieser Vorfall als behoben. Zum zweiten offiziellen Incident (öffnet in neuem Tab)
Intermittierende Fehler in ChatGPT-Unterhaltungen
Einige Nutzer konnten Gespräche nicht laden oder fortsetzen. Der offizielle Eintrag folgte um 00:09 Uhr MESZ; um 01:57 Uhr war eine Gegenmaßnahme aktiv. Zum Redaktionsstand wurde die Erholung weiter überwacht. Zum dritten offiziellen Incident (öffnet in neuem Tab)
Was noch nicht bekannt ist: Für die Vorfälle vom 25. Juli lag zum Redaktionsstand keine technische Ursachenanalyse vor. Ein Cyberangriff, eine Datenpanne oder ein bestimmter Infrastruktur-Anbieter lassen sich daraus nicht ableiten. Auch die Statusseite weist darauf hin, dass aggregierte Verfügbarkeitswerte je nach Tarif, Modell und Funktion von der individuellen Erfahrung abweichen können.
10-Minuten-Notfallplan
Was Sie tun können, wenn ChatGPT nicht funktioniert
Browserdaten zu löschen oder das Gerät neu zu starten kann bei einem lokalen Problem helfen. Bei einem bestätigten Anbieter-Incident beseitigt das jedoch nicht die Ursache. Sinnvoller ist, den Arbeitsstand zu sichern und unnötige Wiederholungsversuche zu vermeiden.
Single Point of Failure
Warum ein KI-Dienst zur geschäftlichen Abhängigkeit werden kann
ChatGPT und vergleichbare Werkzeuge sind inzwischen Teil von Recherche, Texterstellung, Softwareentwicklung, Support und Wissensarbeit. Das spart Zeit – solange klar bleibt, dass ein externer Dienst keine verlässliche Ablage und kein vollständiger Geschäftsprozess ist.
Riskant wird es, wenn Vorlagen nur in Chatverläufen existieren, Entscheidungen nicht außerhalb des Chats dokumentiert werden oder eine Automation ohne Fehlerbehandlung direkt an eine einzelne API gekoppelt ist. Dann kann neben der KI auch das Login, ein Connector, ein Modell, ein Rate Limit oder eine gemeinsame Cloud-Abhängigkeit zum Engpass werden. Selbst ein zweiter KI-Anbieter hilft wenig, wenn ihm die notwendigen Daten fehlen oder seine Nutzung datenschutzrechtlich nicht freigegeben wurde.
Für eine Website gilt deshalb besonders: Navigation, Formulare, Kontaktwege und veröffentlichte Inhalte müssen ohne KI erreichbar bleiben. KI darf beim Erstellen, Prüfen und Optimieren unterstützen; der produktive Betrieb sollte nicht von ihrer spontanen Verfügbarkeit abhängen.
Business Continuity
Eine belastbare Backup-Strategie für KI-gestützte Prozesse
1. Kritische Abläufe und Zielzeiten festlegen
Ordnen Sie jeden Einsatzfall ein: Ist die KI nur Komfortfunktion, unterstützt sie eine Aufgabe oder stoppt ohne sie ein Kundenprozess? Definieren Sie für wichtige Abläufe eine maximale Wiederanlaufzeit (RTO) und den tolerierbaren Verlust von Arbeitsständen (RPO). Ein Kontaktformular sollte ohne Unterbrechung laufen; ein Blogentwurf kann häufig bis zum nächsten Arbeitstag warten.
2. Ein eigenes „System of Record“ pflegen
Finale Texte, Prompt-Vorlagen, Markenregeln, Entscheidungen und Projektdokumentation gehören in kontrollierte Systeme: etwa Git, CRM und eine geschützte Dokumentenablage. So bleiben sie versioniert, durchsuchbar und unabhängig vom Chat-Anbieter. Kundendaten und Zugangsdaten gehören weder ausschließlich in Chatverläufe noch in lose Exportdateien.
OpenAI bietet zwar einen Datenexport an. Dieser kann laut Anbieter bis zu sieben Tage dauern; der Downloadlink ist anschließend 24 Stunden gültig. Der Export ist deshalb ein ergänzendes Archiv, aber kein operatives Backup für laufende Arbeit. Offizielle Anleitung zum ChatGPT-Datenexport (öffnet in neuem Tab)
3. Eigene Daten nach dem 3-2-1-Prinzip sichern
Halten Sie drei Kopien auf zwei unterschiedlichen Systemen oder Medien vor, davon eine räumlich beziehungsweise technisch getrennt. Für eine Agentur bedeutet das beispielsweise: versionierter Projektstand, tägliche Sicherung von Website und CRM sowie eine verschlüsselte Offsite-Kopie außerhalb des Hosters. Entscheidend ist der Wiederherstellungstest – ein Backup, das sich nicht zurückspielen lässt, erfüllt seinen Zweck nicht. Das BSI nennt die 3-2-1-Regel in seinen BCM-Strategien (PDF öffnet in neuem Tab).
4. Alternativen vor dem Ernstfall prüfen
Ein zweiter Anbieter sollte technisch, qualitativ, finanziell und datenschutzrechtlich getestet sein. Ergebnisse verschiedener Modelle sind nicht austauschbar. Übertragen Sie bei einem Wechsel niemals automatisch den gesamten bisherigen Kontext. Für personenbezogene oder vertrauliche Daten müssen Auftragsverarbeitung, Speicherorte, Löschfristen und Drittlandtransfers separat bewertet werden. Mehr dazu finden Sie in meiner Datenschutzberatung für digitale Prozesse.
5. Einen manuellen Notbetrieb dokumentieren
Ein einseitiges Runbook sollte Zuständigkeiten, Statusprüfung, Pausieren von Automationen, lokale Aufgabenliste, freigegebene Vorlagen und den kontrollierten Wiederanlauf beschreiben. Wiederkehrende Jobs müssen nach einem Fehler idempotent fortgesetzt werden können: derselbe Auftrag darf nicht doppelt veröffentlicht, versendet oder berechnet werden.
6. Überwachen, testen und lernen
Abonnieren Sie offizielle Statusmeldungen, messen Sie bei API-Prozessen Fehlerrate und Antwortzeit und unterscheiden Sie Providerstörung, Netzwerkfehler, Authentifizierung und Nutzungslimit. Speichern Sie in technischen Logs keine vollständigen Prompts oder Kundentexte. Testen Sie den Notbetrieb mindestens quartalsweise und aktualisieren Sie den Plan nach jedem echten Vorfall.
Meine Einordnung
KI sollte ein starkes Werkzeug sein – nicht die einzige tragende Säule
Der Ausfall vom 25. Juli ist kein Argument gegen KI. Er ist ein Argument für professionelle Architektur. Unternehmen gewinnen, wenn sie KI produktiv einsetzen und zugleich Datenhoheit, manuelle Handlungsfähigkeit sowie technische Ausweichwege behalten. In meinen eigenen Projekten bleiben Website-Code und Inhalte deshalb versioniert, Anfragen im dafür vorgesehenen System und produktive Kontaktwege unabhängig von einem KI-Anbieter.
Wenn Sie ChatGPT bereits in Abläufe eingebunden haben, lohnt sich eine kurze Bestandsaufnahme: Wo entsteht echter Nutzen, wo ein unbemerkter Single Point of Failure und welche Informationen müssten heute außerhalb des Chats gesichert werden? Passende Grundlagen finden Sie auch in meinem Beitrag Arbeitsprozesse mit ChatGPT optimieren.
Häufige Fragen
FAQ zur ChatGPT-Störung
War ChatGPT am 25. Juli 2026 weltweit komplett offline?
Nein, ein vollständiger weltweiter Totalausfall ist durch die offiziellen Angaben nicht belegt. OpenAI meldete drei Vorfälle mit erhöhten Fehlerraten beziehungsweise intermittierenden Fehlern. Die individuelle Auswirkung konnte je nach Tarif, Modell und Funktion unterschiedlich sein.
Wie lange dauerten die Störungen?
Der erste Vorfall dauerte offiziell rund 1 Stunde und 51 Minuten, der zweite rund 22 Minuten. Beim dritten Vorfall begann die Auswirkung laut OpenAI gegen 22:00 Uhr MESZ; um 01:57 Uhr MESZ am Folgetag war eine Gegenmaßnahme umgesetzt und die Wiederherstellung wurde überwacht.
Was war die Ursache des ChatGPT-Ausfalls?
OpenAI hatte zum Redaktionsstand keine technische Ursache für die Vorfälle vom 25. Juli veröffentlicht. Behauptungen über einen Cyberangriff, Datenverlust oder einen bestimmten Infrastruktur-Anbieter wären daher Spekulation.
Sind bei einer solchen Störung meine Chatverläufe verloren?
Eine Störung ist nicht automatisch ein Datenverlust. Trotzdem sollten geschäftskritische Informationen nie ausschließlich in einem Chat liegen. Ein ChatGPT-Datenexport ist ein ergänzendes Archiv, aber wegen möglicher Wartezeit kein operatives Backup.
Reicht ein zweiter KI-Anbieter als Backup?
Nein. Ein belastbarer Notfallplan umfasst eigene Datenbestände, dokumentierte manuelle Abläufe, freigegebene Alternativen, klare Zuständigkeiten und regelmäßige Wiederherstellungstests. Ein Ersatzanbieter ist nur ein Baustein davon.
Quellen und Transparenz
Die Chronologie basiert auf den offiziellen OpenAI-Incident-Seiten und deren UTC-Zeitstempeln. Externe Links wurden zuletzt am 26. Juli 2026 geprüft.