ChatGPT, Claude en Grok vielen tegelijk uit: wat zegt het openbare bewijs?

Bijna gelijktijdige fouten bij Grok, ChatGPT/Codex en Claude wekten begrijpelijkerwijs de indruk van één brede AI-infrastructuurstoring. Het openbare feitenmateriaal leidt echter tot een beperktere conclusie: de incidenten overlapten, maar de aanbieders noemden verschillende oorzaken en er is geen bewijs voor één gezamenlijke cascade.

Wat per aanbieder is bevestigd

Grok: bevestigde storing in een rekencentrum in Memphis

SpaceXAI verklaarde dat de problemen met Grok volgden op een storing in het compute center in Memphis en bood excuses aan aan getroffen ‘compute partners’. Volgens de berichtgeving begon de verstoring van Grok rond 06.30 uur Pacific Time en duurde deze meer dan drie uur, voordat de systemen waren hersteld. 3941

Dat is direct bewijs van een incident in de faciliteit in Memphis én van gevolgen buiten Grok zelf. Publiekelijk is echter niet bekendgemaakt welke partners getroffen waren, wat de technische fout precies was of welke externe diensten daar eventueel draaiden.

ChatGPT en Codex: bevestigde routeringsfout

OpenAI schreef de storing bij ChatGPT en Codex toe aan een routeringsfout die op 3 september rond 07.43 uur Pacific Time begon. Rond 08.17 uur was een oplossing doorgevoerd; daarna bleef het bedrijf het herstel monitoren. 39

Dit is bevestigend bewijs voor een routeringsprobleem aan de kant van OpenAI. Het is geen bewijs dat het incident in Memphis de OpenAI-storing veroorzaakte.

Claude: verhoogde foutpercentages en herstel, maar geen gedetailleerde openbare oorzaak

Op de statuspagina van Anthropic stond dat meerdere Claude-modellen verhoogde foutpercentages hadden; de impact eindigde volgens die pagina om 09.16 uur Pacific Time / 16.16 uur UTC. 33 In berichtgeving uit die periode werd het omschreven als een gedeeltelijke storing door een infrastructuurprobleem. 28

Het beschikbare openbare materiaal noemt geen gedetailleerde grondoorzaak en legt geen verband tussen Claudes incident en de faciliteit in Memphis. De verdedigbare conclusie is dus dat Claude een reële, inmiddels opgeloste storing had, terwijl de onderliggende oorzaak in de publieke documentatie onduidelijk blijft.

Waarom gelijktijdigheid geen oorzakelijk verband bewijst

De diensten vielen niet allemaal uit op één exact gedocumenteerd moment. De gemelde Grok-storing begon eerder; OpenAI gaf een venster van 07.43 tot 08.17 uur Pacific Time voor zijn routeringsfout; Anthropic meldde dat de impact voor Claude om 09.16 uur Pacific Time eindigde. 3339

Die overlap is operationeel wel degelijk belangrijk: klanten die op meerdere AI-diensten vertrouwden, hadden tijdelijk minder of geen bruikbare alternatieven. Maar een samenloop in de tijd bewijst geen gedeelde technische oorzaak. Een gezamenlijke afhankelijkheid, extra verkeersdruk door uitwijkende gebruikers of een kettingreactie zijn hypotheses totdat aanbieders daar bewijs voor publiceren.

Wat niet is bewezen

Het beschikbare bewijs toont niet aan:

• dat er één cascaderende storing was bij Grok, ChatGPT/Codex en Claude;
• dat OpenAI of Anthropic productiecapaciteit voor inferentie gebruikte op de getroffen locatie in Memphis;
• dat Azure, Cloudflare of een andere genoemde cloud-, CDN- of netwerkpartij de gezamenlijke oorzaak was;
• hoeveel unieke gebruikers precies werden geraakt op basis van meldingen op storingssites; of
• dat een specifieke fout in Cursor, een onderbroken code-agent of een downstreamworkflow door één van deze incidenten werd veroorzaakt in plaats van door een integratie-, authenticatie-, wachtrij-, rate-limit-, netwerk- of clientprobleem.

De statuspagina van Cursor meldde wel verhoogde fouten voor upstreammodellen van OpenAI en Anthropic. Dat ondersteunt een aanbiedergerelateerde verklaring voor een deel van de getroffen Cursor-activiteit. Maar het bewijst niet de oorzaak van elke mislukte agentbeurt of klantworkflow. 30

De echte les: meerdere modellen betekent niet automatisch veerkracht

De verwijzing naar niet nader genoemde compute partners in Memphis herinnert eraan hoe ondoorzichtig infrastructuurafhankelijkheden vaak zijn. Een applicatie kan API’s van meerdere modelaanbieders gebruiken en toch afhankelijk zijn van dezelfde identiteitsdienst, DNS- of CDN-route, cloudregio, GPU-host, modelgateway, codehost, observabilitydienst of toolbackend.

Met andere woorden: diversiteit tussen aanbieders op API-niveau is niet automatisch diversiteit in de onderliggende infrastructuur. Een reserve-endpoint voor een model heeft alleen waarde als de omringende afhankelijkheden het storingsscenario ook kunnen overleven.

Zo bereidt u zich voor op AI-storingen van meerdere uren

Breng de volledige afhankelijkheidsketen in kaart

Onderhoud een servicekaart met alle kritieke afhankelijkheden: model-API, gateway, cloudregio, DNS/CDN, identiteit, vectordatabase, wachtrij, codehost, toolintegraties en observabilitystack. Leg zowel bevestigde onderaannemers als belangrijke onbekenden vast.

Test uitwijkroutes onder echte belasting

Integreer alternatieve aanbieders of kleinere, lokale modellen vooraf en test failover met realistische prompts, gestructureerde uitvoer, toolaanroepen, veiligheidsvereisten, doorvoercapaciteit en kostenlimieten. Een geslaagde demoverzoek is geen bewijs dat een alternatief een productieproces kan dragen.

Ontwerp agenten die veilig falen

Gebruik time-outs, begrensde retries met jitter, circuit breakers, idempotency keys, duurzame checkpoints en expliciete pauzeer-/hervatsemantiek. Vereis menselijke goedkeuring vóór onomkeerbare acties. Na een storing moet een agent vanuit de vastgelegde toestand kunnen hervatten, zonder bijvoorbeeld een deployment, aankoop, ticket of externe API-aanroep dubbel uit te voeren.

Leg noodmodi vóór een incident vast

Documenteer wat zonder modeltoegang blijft werken: zoeken, formulieren, regelgebaseerde routering, uitgestelde conceptvorming, alleen-lezen-toegang, handmatige escalatie en een duidelijke klantmelding. Bepaal praktische grenzen voor maximale wachtrijleeftijd, capaciteit voor handmatig werk, klantcommunicatie en het moment waarop autonome acties moeten worden uitgeschakeld.

Verbeter leverancierscommunicatie en incidentbewijs

Abonneer u op statusfeeds van leveranciers en spreek escalatiepaden, verwachtingen voor meldingen, eisen voor post-incidentrapporten en voorwaarden voor dataportabiliteit af, waar contracten dat toelaten. Bewaar tijdens een incident UTC-tijdstempels, request-ID’s, responseheaders, foutmeldingen, traces, routeringsgegevens, agentstatus, wachtrijlogs en snapshots van statuspagina’s. Dat bewijs is essentieel om een storing bij een upstreamprovider te onderscheiden van een fout in de eigen integratie.

Zoek onafhankelijkheid waar die ertoe doet

Kies voor bedrijfskritieke processen alternatieven die niet alleen verschillen in modelmerk, maar ook in aanbieder, regio, cloud, netwerkpad, authenticatieafhankelijkheid en operationeel controlevlak. Twee modelendpoints achter dezelfde gateway of in dezelfde regio vormen geen betekenisvolle redundantie.

Conclusie

De verstoringen van 3 september mogen niet worden gelezen als bewijs voor een universele AI-storing of een bevestigde cascade vanuit Memphis. Ze laten wel zien waarom organisaties ervan moeten uitgaan dat ogenschijnlijk onafhankelijke AI-diensten in hetzelfde tijdvenster kunnen falen — en systemen moeten bouwen die veilig kunnen doorwerken terwijl het feitenbeeld pas later helder wordt. 333941