Samtidige AI-feil viste skjulte avhengigheter, men ikke én felles årsak

Da Grok, ChatGPT/Codex og Claude fikk problemer i omtrent samme tidsrom, var det nærliggende å mistenke én stor feil i AI-infrastrukturen. Den offentlige informasjonen støtter imidlertid en smalere konklusjon: Hendelsene overlappet, men leverandørene oppga ulike forklaringer, og det finnes ingen bekreftelse på én felles kjedefeil på tvers av alle tre.

Hva leverandørene faktisk har bekreftet

Grok: bekreftet feil ved et datasenter i Memphis

SpaceXAI opplyste at Grok-problemene fulgte etter et avbrudd ved selskapets databehandlingssenter i Memphis, og ba samtidig om unnskyldning til berørte «compute partners». Rapporteringen tyder på at Grok-feilen startet rundt kl. 06.30 stillehavstid og varte i mer enn tre timer før systemene ble gjenopprettet. 3941

Dette er direkte dokumentasjon på en hendelse ved anlegget i Memphis, og på at andre enn Grok ble berørt. Det offentliggjør derimot ikke hvem partnerne var, den konkrete tekniske feilmodusen eller hvilke eksterne tjenester – om noen – som kjørte der.

ChatGPT og Codex: bekreftet ruterfeil

OpenAI forklarte at avbruddet for ChatGPT og Codex skyldtes en ruterfeil som begynte rundt kl. 07.43 stillehavstid 3. september. En løsning ble satt i verk rundt kl. 08.17, før selskapet fortsatte å overvåke gjenopprettingen. 39

Det dokumenterer en feil på OpenAIs side. Det dokumenterer ikke at hendelsen i Memphis forårsaket OpenAI-problemene.

Claude: forhøyet feilrate og gjenoppretting, men ingen detaljert offentlig rotårsak

Anthropics statusside registrerte forhøyet feilrate for flere Claude-modeller og opplyste at påvirkningen var over kl. 09.16 stillehavstid / 16.16 UTC. 33 Samtidig rapportering omtalte hendelsen som et delvis avbrudd forårsaket av et infrastrukturproblem. 28

Det tilgjengelige offentlige materialet oppgir likevel ingen detaljert rotårsak, og etablerer ingen kobling mellom Claude-hendelsen og anlegget i Memphis. Den forsvarlige konklusjonen er at Claude hadde en reell, løst hendelse, men at den underliggende årsaken fortsatt ikke er avklart i detalj i offentligheten.

Hvorfor samtidig timing ikke beviser årsakssammenheng

Tjenestene sviktet ikke på ett enkelt, dokumentert tidspunkt. Groks rapporterte hendelse startet tidligere. OpenAI oppga et tidsrom fra kl. 07.43 til 08.17 stillehavstid for ruterfeilen, mens Anthropic opplyste at Claude-påvirkningen var over kl. 09.16. 3339

Overlappet er operativt viktig: Kunder som var avhengige av flere AI-tjenester, kunne oppleve at flere alternativer var svekket samtidig. Men tidsmessig sammenfall beviser ikke en felles teknisk årsak. Felles underleverandører, trafikk som flyttes mellom tjenester, eller en kjedereaksjon er hypoteser inntil leverandørene legger fram bevis.

Dette er fortsatt ikke dokumentert

Den tilgjengelige dokumentasjonen fastslår ikke:

• at det var én sammenhengende kjedefeil hos Grok, ChatGPT/Codex og Claude;
• at OpenAI eller Anthropic hadde produksjonskapasitet for inferens ved det berørte Memphis-anlegget;
• at Azure, Cloudflare eller en annen navngitt sky-, CDN- eller nettverksleverandør var en felles årsaksfaktor;
• et revidert totalt antall berørte brukere basert på nettsteder som samler inn feilrapporter; eller
• at en bestemt Cursor-feil, avbrutt kodeagent eller nedstrøms arbeidsflyt skyldtes én av disse hendelsene framfor integrasjons-, autentiserings-, kø-, rate-limit-, nettverks- eller klientfeil.

Cursors statusside rapporterte forhøyet feilrate for oppstrømsmodeller fra OpenAI og Anthropic. Det kan støtte en leverandørrelatert forklaring for enkelte Cursor-problemer, men beviser ikke årsaken til hver enkelt mislykkede agentforespørsel eller arbeidsflyt. 30

Den viktigste lærdommen: Flere modeller betyr ikke automatisk robusthet

Henvisningen til navnløse databehandlingspartnere i Memphis minner om at infrastrukturavhengigheter ofte er lite synlige. En applikasjon kan benytte flere modellleverandører, men fortsatt være avhengig av den samme identitetsleverandøren, DNS- eller CDN-ruten, skyregionen, GPU-verten, modellgatewayen, kodeverten, overvåkingstjenesten eller verktøysintegrasjonen.

Med andre ord: Mangfold av leverandører på API-nivå er ikke nødvendigvis mangfold i infrastrukturen. Et reserveendepunkt for en modell har bare verdi dersom også de omkringliggende avhengighetene tåler feilsituasjonen.

Slik kan virksomheter forberede seg på fler timers AI-avbrudd

Kartlegg hele avhengighetskjeden

Hold et tjenestekart oppdatert med alle kritiske avhengigheter: modell-API, gateway, skyregion, DNS/CDN, identitet, vektordatabase, kø, kodevert, verktøyintegrasjoner og observability-/overvåkingsløsninger. Noter både bekreftede underleverandører og vesentlige ukjente forhold.

Test reserveveier under realistisk belastning

Integrer alternative leverandører eller mindre/lokale modeller på forhånd. Test så failover med realistiske forespørsler, strukturerte svar, verktøykall, sikkerhetskrav, kapasitetsgrenser og kostnadskontroller. En vellykket demoforespørsel er ikke bevis på at et reserveoppsett kan drive en produksjonsprosess.

Bygg agenter som feiler trygt

Bruk tidsavbrudd, begrensede forsøk med jitter, circuit breakers, idempotensnøkler, varige kontrollpunkter og tydelig semantikk for pause og gjenopptakelse. Krev menneskelig godkjenning før irreversible handlinger. Etter et avbrudd bør en agent fortsette fra lagret tilstand – ikke opprette et dobbelt kjøp, en ny utrulling, en ny sak eller et nytt kall mot en ekstern API.

Definer degraderte driftsmoduser før hendelsen

Dokumenter hva som fortsatt fungerer uten modelltilgang: søk, skjemaer, regelbasert ruting, utkast som settes i kø, skrivebeskyttet tilgang, manuell eskalering og tydelig kundekommunikasjon. Sett praktiske mål for maksimal alder på køer, kapasitet til manuelt arbeid, varsling av kunder og når autonome handlinger skal slås av.

Styrk leverandørdialogen og bevisgrunnlaget ved hendelser

Abonner på leverandørenes statusvarsler og avtal eskaleringsveier, forventninger til varsling, krav om rapporter etter hendelser og vilkår for dataportabilitet der kontrakten åpner for det. Under en hendelse bør man ta vare på UTC-tidsstempler, forespørsels-ID-er, responshoder, feilmeldinger, sporingsdata, ruteopplysninger, agenttilstand, kølogger og øyeblikksbilder av statussider. Dette er nødvendig for å skille et oppstrøms leverandøravbrudd fra feil i egen integrasjon.

Sørg for reell uavhengighet der konsekvensene er store

For arbeidsflyter med høy risiko bør alternativene avvike ikke bare i modellnavn, men også i leverandør, region, skyplattform, nettverksvei, autentiseringsavhengighet og operativ kontrollflate. To modellendepunkter bak samme gateway eller i samme region er ikke meningsfull redundans.

Konklusjon

Forstyrrelsene 3. september bør ikke behandles som bevis på et universelt AI-avbrudd eller en bekreftet Memphis-drevet kjedereaksjon. De viser derimot hvorfor virksomheter bør planlegge for at tilsynelatende uavhengige AI-tjenester kan svikte i samme tidsrom – og bygge systemer som kan fortsette på en trygg måte mens fakta fortsatt avklares. 333941