Zusammenfassung

  • Anthropic stufte q2kg8n613kr3 als kritisch ein und setzte claude.ai, Claude API, Claude Code und Claude Cowork zunächst von betriebsbereit auf großen Ausfall.
  • Der spätere Rückblick grenzt erhöhte Fehlerraten über Claude-Modelle auf 19:45 bis 21:26 UTC am 29. Juli ein, ein Symptomfenster von 101 Minuten.
  • Der öffentliche Incident lief von 19:49:45 bis zur Lösung um 22:36:20 UTC und damit rund 171 Minuten durch Untersuchung, Erholung und Bestätigung.
  • Um 21:38 erholten sich die meisten Modelle, während Anfragen und Latenz noch erhöht waren; beim Monitoring um 22:20 wechselten alle vier Oberflächen wieder auf betriebsbereit.
  • Anthropic veröffentlichte keine Root Cause, Fehlercodes, Anfragebasis, endgültige Fehlerquote, Kunden- oder Regionszahl, Mitigation, Datenintegritätsaussage oder Nachanalyse.
  • Ein zeitlich überlappender GitHub-Copilot-Incident nennt den externen Modellanbieter nicht; die Uhrzeiten identifizieren Anthropic nicht und beweisen keine gemeinsame Ursache.

Die Meldung bildet Zustände ab, nicht das Geschäftsvolumen

Statuspages reduzieren komplexe Systeme auf wenige Kategorien. In diesem Fall ist diese Abbildung breit: claude.ai, die direkte API, Claude Code und Cowork wechselten beim Untersuchungsbeginn gemeinsam von betriebsbereit zu einem großen Ausfall. Der Titel erweiterte den Umfang auf alle Claude-Modelle; die öffentliche Impact-Klasse lautete kritisch.

Keine dieser Kategorien ist ein Nenner. Sie sagt nicht, ob ein Prozent oder ein großer Anteil aller Anfragen scheiterte. Sie trennt auch nicht erste Fehlversuche, erfolgreiche Wiederholungen und endgültig aufgegebene Vorgänge. Kunden, Organisationen, Regionen, Modelle und Lastarten bleiben ohne quantitative Verteilung.

„Kritisch“ ist deshalb ein Eskalationssignal, keine Messzahl. „Alle Modelle“ beschreibt den Umfang des Katalogs, nicht den Ausfall jeder einzelnen Anfrage. Anthropic sprach von erhöhten Raten und einer schrittweisen Erholung. Ein vollständiger Totalausfall wäre eine stärkere Behauptung als die Quelle erlaubt.

Vier gleichzeitige Zustände markieren eine gemeinsame Betriebsfläche

Um 20:33 UTC meldete Anthropic ein identifiziertes Problem, das über mehrere Modelle erhöhte Fehler verursache. Um 21:38 zeige sich auf den meisten Modellen eine Erholung; Anfragen und Latenz seien aber noch erhöht. Zu diesem Zeitpunkt gingen alle vier Komponenten vom großen zum teilweisen Ausfall über.

Um 22:20 wechselten sie gemeinsam auf betriebsbereit und der Incident ging in die Beobachtung. Sechzehn Minuten später folgte die Lösung. Für Kunden zeigt die Synchronität, dass Weboberfläche, API und agentische Arbeitswerkzeuge im veröffentlichten Störungsbereich lagen. Ein Wechsel zwischen diesen Zugängen war kein belegter Failover.

Die gemeinsame Bewegung verrät jedoch keine Architektur. Modellbereitstellung, Traffic-Steuerung, eine Abhängigkeit, ein Release oder nur die Gruppierungslogik der Statuspage könnten dasselbe Bild erzeugen. Anthropic nannte keine dieser Ebenen. Der Befund lautet gemeinsamer Betriebsbereich, nicht gemeinsame technische Root Cause.

Ebenso wenig belegt der Incident einen Fehler der Modellgewichte oder Inhalte. Eine Anfrage kann vor der Inferenz, im Streaming oder in einer Werkzeugkette scheitern. Claude Code und Cowork haben Sitzungs- und Ausführungszustände oberhalb des Modellaufrufs. Datenverlust, beschädigte Antworten, Exfiltration oder versagende Sicherheitskontrollen wurden weder festgestellt noch ausgeschlossen.

Zwei Zeitachsen schützen vor einer falschen Dauer

Der öffentliche Datensatz begann um 19:49:45 UTC. Im späteren Monitoring setzte Anthropic den Beginn der erhöhten Fehlerraten rückwirkend auf 19:45 und ihr Ende auf 21:26. Dieses Symptomfenster dauert 101 Minuten und beginnt knapp fünf Minuten vor dem ersten Eintrag.

Gelöst wurde die Seite erst um 22:36:20. Von der Eröffnung bis zur Lösung vergingen etwa 171 Minuten. Darin stecken Untersuchung, Identifizierung, Teilerholung, Beobachtung und Bestätigung. Alle 171 Minuten als fortlaufende Fehlerphase auszugeben, würde der späteren Eingrenzung widersprechen.

Nur die 101 Minuten zu nennen, würde dagegen den Wiederanlauf verkürzen. Nach 21:26 blieben die Komponenten zunächst im Teilstatus. Nach 22:20 lief noch eine ausdrücklich ausgewiesene Beobachtungsphase. Für eine Kundenwarteschlange sind Ende des Symptoms und Vertrauen in eine stabile Erholung zwei verschiedene Zeitpunkte.

Retry-Logik verschiebt die Messgrenze

Anthropics allgemeine API-Dokumentation bezeichnet 500 als internen API-Fehler und 529 als temporäre Überlastung. Offizielle SDKs wiederholen vorübergehende Verbindungs-, Limit- und 5xx-Fehler standardmäßig zweimal mit exponentiellem Backoff.

Das ist keine Diagnose dieses Incidents. Die Statusseite veröffentlichte weder HTTP-Codes noch die Feststellung einer Überlastung. Die normale Logik erklärt aber, warum ein bloßer Request-Zähler nicht genügt. Eine Geschäftsoperation kann beim ersten Aufruf scheitern und beim zweiten gelingen. Der Nutzer sieht Verzögerung, Anthropic sieht zwei Versuche, und die Anwendung verbucht womöglich einen endgültigen Erfolg.

Gleichzeitige Wiederholungen können die Anzahl technischer Versuche auch über die ursprüngliche Nachfrage heben. Die Meldung von erhöhten Anfragen und Latenz um 21:38 belegt nicht, dass dieser Effekt auftrat. Messbar würde er erst durch getrennte Zähler für ursprüngliche Operationen, Gesamtversuche, Wiederholungen und terminale Fehler.

Die dokumentierten Request-IDs schaffen die Verbindung zur Einzelfallanfrage. Wer ID, Modell, Zeit und Endergebnis speichert, kann Supportdaten korrelieren. Die aggregierte Farbe einer Komponente ersetzt diesen Pfad nicht.

Wiederanlauf gehört an die Grenze der echten Arbeitslast

Ein grüner Providerstatus darf eine Prüfung starten, nicht automatisch den gesamten Rückstau freigeben. Ein Team kann kleine synthetische Anfragen mit genau dem Modell, der Kontextgröße, dem Streaming und den Werkzeugen seiner Produktion senden. Danach öffnet es Traffic stufenweise und beobachtet Endfehler, Latenz, Warteschlangenalter und fachliche Abschlussrate.

Vier Oberflächen benötigen getrennte Gesundheitssignale. Ein kurzer API-Aufruf kann bereits funktionieren, während eine lange Claude-Code-Sitzung oder ein Cowork-Ablauf noch instabil ist. Umgekehrt kann eine App-Oberfläche leiden, obwohl die API verwendbar bleibt. Die Probe muss die bezahlte Arbeitsleistung darstellen.

Idempotenz ist Teil der Erholung. Wenn nur die Antwort verloren ging, der externe Effekt aber ausgeführt wurde, erzeugt blindes Wiederholen ein Duplikat. Auch ein Ersatzmodell oder zweiter Anbieter ist nicht gleichwertig: Qualität, Preis, Kontext, Tools, Sicherheitsverhalten und Datenpfad können sich ändern. Der Plan muss vorher festlegen, welche Aufgaben umgeleitet werden dürfen.

GitHubs paralleler Incident bleibt namenlos

GitHub eröffnete um 20:07 UTC einen eigenen Copilot-Incident zu KI-Modellanbietern. Die Meldungen nannten erhöhte Fehler bei Anfragen an bestimmte oder externe Anbieter und mögliche Fehlschläge oder Leistungseinbußen für einige Nutzer. Um 21:51 sei das Problem beim externen Anbieter gelöst und der Copilot-Traffic wiederhergestellt gewesen.

Die Zeit überschneidet sich mit Anthropic. GitHub nannte jedoch weder den Anbieter noch Modelle oder Ursache. Ein Produkt kann mehrere Anbieter nutzen, und unabhängige Störungen können gleichzeitig auftreten. Die zeitliche Korrelation ist daher kein Beleg dafür, dass Anthropic GitHubs ungenannter Anbieter war.

Der Vergleich zeigt nur die mögliche Wirkungskette: Ein Modellanbieterfehler kann als Störung einer nachgelagerten Plattform erscheinen, während die öffentliche Lieferkette unvollständig bleibt. Eine Verbindung braucht eine Benennung oder gemeinsame technische Evidenz.

Eine Nachanalyse muss Rate, Schicht und Korrektur ergänzen

Der Incident liefert eine belastbare Abfolge: kritische Einstufung, alle Modelle, vier Produktoberflächen, Teilwiederherstellung, Monitoring und Lösung. Eine brauchbare Nachanalyse müsste nun maximale und durchschnittliche terminale Fehlerraten, Gesamtvolumen, Ergebnisse vor und nach Wiederholung, betroffene Regionen und Organisationen sowie Unterschiede zwischen API, App, Code und Cowork offenlegen.

Außerdem braucht sie die fehlerhafte Schicht, die Mitigation oder Rücknahme und die neue Kontrolle gegen Wiederholung. Aussagen zu Datenintegrität, Sicherheit und Schutzmechanismen sollten ausdrücklich sein. Schweigen ist weder ein Nachweis für Schaden noch für dessen Abwesenheit.

Der enge Befund ist bereits erheblich: Alle Modelle und vier Oberflächen lagen in einem kritischen Incident, die beobachteten Fehler dauerten 101 Minuten und die öffentliche Reaktion bis zur Lösung rund 171 Minuten. Sichtbar sind Ort und Reihenfolge der Erholung. Unsichtbar bleiben die Zahl endgültig gescheiterter Geschäftsoperationen und das Warum. Genau dieser fehlende Nenner begrenzt die Resilienzanalyse.

Quellen