Hvad skete der 16. august?

Anthropic beskrev først et problem, der forhindrede nogle brugere i at logge ind på claude.ai, Claude Code og Claude Cowork. Senere opdateringer viste, at flere tjenester var berørt, herunder platform.claude.com, Claude API, Claude Code og Claude Cowork.

For brugerne viste problemet sig blandt andet som mislykkede loginforsøg, sider der ikke indlæste, forespørgsler der ikke blev gennemført, og generelt forringet ydeevne. Anthropic oplyste, at en løsning var implementeret, og at virksomheden overvågede genoprettelsen. Den tilgængelige hændelsesrapport indeholdt dog ingen forklaring på den bagvedliggende årsag.

Tidslinjen kort fortalt

• 21.58 UTC, 16. august: Anthropic begyndte at undersøge autentificeringsproblemer, der berørte nogle brugere.
• Kort efter: Problemet bredte sig til forringet ydeevne på flere Claude-tjenester.
• 22.34 UTC: Anthropic markerede de berørte tjenester som genoprettede.

Hvor mange Downdetector-rapporter var der?

Medier, der dækkede hændelsen 16. august, skrev, at antallet af Downdetector-rapporter toppede på mere end 15.000. Tallet skal dog fortolkes med forsigtighed. Downdetector bygger på indberetninger fra brugere og måler hverken antallet af berørte kunder, fejlslagne API-kald eller hvor længe den enkelte bruger var ramt.

Der findes ingen pålidelig kilde i det fremlagte materiale, som fastslår et Downdetector-tal for en Anthropic-nedetid 18. august. Tallet på mere end 15.000 bør derfor ikke henføres til denne dato.

Hvorfor mærkede Claude Code-brugere problemet tydeligt?

Claude Code var blandt de berørte tjenester. For udviklere har et autentificeringsproblem en anden praktisk konsekvens end et langsomt eller ufuldstændigt svar fra en chatbot. Hvis et kodeværktøj ikke kan godkende brugeren, kan det forhindre oprettelsen af en session, afbryde en eksisterende arbejdsgang eller blokere en opgave i terminalen eller udviklingsmiljøet.

Det forklarer, hvorfor autentificeringsfejl kan opleves som særligt indgribende i udviklingsmiljøer: De kan stoppe arbejdet allerede ved indgangen. Der er dog ikke tilstrækkelig dokumentation til at fastslå en særskilt Claude Code-fejltype eller opgøre antallet af Claude Code-klager den 18. august.

Hvordan står hændelsen i forhold til andre forstyrrelser i 2026?

Hændelsen 16. august var forholdsvis kort, men ramte flere produktflader på samme tid. En separat hændelse 12. august omfattede forhøjede fejl på flere Claude-modeller samt forringet ydeevne på claude.ai, Claude API, Claude Code og Claude Cowork. Problemet blev meldt løst senere samme dag.

Andre medier beskrev også en væsentligt længere forstyrrelse 5. august, men de fremlagte kilder giver ikke et tilstrækkeligt ensartet hændelsesregister til at understøtte et præcist samlet antal Claude-nedetider i 2026. Den forsvarlige konklusion er derfor mere begrænset: Claude har været ramt af flere rapporterede forstyrrelser, men opgørelser og sammenligninger afhænger af, hvordan en hændelse defineres og dokumenteres.

Hvad betyder det for systemer i produktion?

Hændelsen 16. august illustrerer en vigtig driftsrisiko for virksomheder, der bygger på AI-API'er. Den umiddelbare fejl var autentificering – ikke et dokumenteret problem med modellens kvalitet – men en fælles adgangsafhængighed påvirkede web-, kode- og API-arbejdsgange på samme tid. En leverandør kan altså blive utilgængelig, selv om den underliggende model ikke er den direkte årsag til fejlen.

Der er ingen dokumentation i de fremlagte kilder for, at stigende brug blandt virksomheder eller forbrugere forårsagede hændelsen 16. august. Anthropic har heller ikke oplyst, at hændelsen hænger sammen med den påståede nedetid 18. august.

Sådan kan API-afhængige systemer gøres mere robuste

1. Fastlæg tilgængelighedsmål og alternativer. Behandl modelleverandøren som en ekstern afhængighed med et tydeligt SLO og en afprøvet plan for fejl.
2. Brug begrænsede genforsøg. Anvend eksponentiel backoff, tilfældig spredning, faste grænser for genforsøg og idempotens, hvor det er relevant. Undgå genforsøgsstorme under brede leverandørproblemer.
3. Forbered skift af leverandør eller model. Send egnede opgaver videre til et alternativ, men test først kompatibilitet, kvalitet, svartid, pris og krav til datahåndtering.
4. Lad systemet fungere med færre funktioner. Læg ikke-hastende opgaver i kø, gem brugerinput, understøt asynkron færdiggørelse og tilbyd en sikker nødløsning med begrænset funktionalitet.
5. Hold kritiske handlinger uafhængige. Lad ikke login, betaling, sikkerhedsovervågning eller irreversible handlinger afhænge synkront af ét LLM-kald.
6. Overvåg egne målepunkter. Følg succesrate, svartid, tid til første token, fejlkategorier, timeouts og afbrudte streams i stedet for udelukkende at stole på leverandørens statusside.
7. Øv nødskift regelmæssigt. Simulér autentificeringsfejl som 401 og 403, rate limits, 5xx-fejl, timeouts og afbrudte streaming-svar.

Den klareste konklusion er ikke, at Claude havde en bekræftet nedetid 18. august. Det er, at den verificerede hændelse 16. august viste, hvordan en kortvarig autentificeringsfejl kan brede sig på tværs af flere grænseflader – og hvorfor systemer i produktion bør være designet til at fortsætte, når én AI-leverandør bliver utilgængelig.

Hvad skete der 16. august?

Anthropic beskrev først et problem, der forhindrede nogle brugere i at logge ind på claude.ai, Claude Code og Claude Cowork. Senere opdateringer viste, at flere tjenester var berørt, herunder platform.claude.com, Claude API, Claude Code og Claude Cowork.

For brugerne viste problemet sig blandt andet som mislykkede loginforsøg, sider der ikke indlæste, forespørgsler der ikke blev gennemført, og generelt forringet ydeevne. Anthropic oplyste, at en løsning var implementeret, og at virksomheden overvågede genoprettelsen. Den tilgængelige hændelsesrapport indeholdt dog ingen forklaring på den bagvedliggende årsag.

Tidslinjen kort fortalt

• 21.58 UTC, 16. august: Anthropic begyndte at undersøge autentificeringsproblemer, der berørte nogle brugere.
• Kort efter: Problemet bredte sig til forringet ydeevne på flere Claude-tjenester.
• 22.34 UTC: Anthropic markerede de berørte tjenester som genoprettede.

Hvor mange Downdetector-rapporter var der?

Medier, der dækkede hændelsen 16. august, skrev, at antallet af Downdetector-rapporter toppede på mere end 15.000. Tallet skal dog fortolkes med forsigtighed. Downdetector bygger på indberetninger fra brugere og måler hverken antallet af berørte kunder, fejlslagne API-kald eller hvor længe den enkelte bruger var ramt.

Der findes ingen pålidelig kilde i det fremlagte materiale, som fastslår et Downdetector-tal for en Anthropic-nedetid 18. august. Tallet på mere end 15.000 bør derfor ikke henføres til denne dato.

Hvorfor mærkede Claude Code-brugere problemet tydeligt?

Claude Code var blandt de berørte tjenester. For udviklere har et autentificeringsproblem en anden praktisk konsekvens end et langsomt eller ufuldstændigt svar fra en chatbot. Hvis et kodeværktøj ikke kan godkende brugeren, kan det forhindre oprettelsen af en session, afbryde en eksisterende arbejdsgang eller blokere en opgave i terminalen eller udviklingsmiljøet.

Det forklarer, hvorfor autentificeringsfejl kan opleves som særligt indgribende i udviklingsmiljøer: De kan stoppe arbejdet allerede ved indgangen. Der er dog ikke tilstrækkelig dokumentation til at fastslå en særskilt Claude Code-fejltype eller opgøre antallet af Claude Code-klager den 18. august.

Hvordan står hændelsen i forhold til andre forstyrrelser i 2026?

Hændelsen 16. august var forholdsvis kort, men ramte flere produktflader på samme tid. En separat hændelse 12. august omfattede forhøjede fejl på flere Claude-modeller samt forringet ydeevne på claude.ai, Claude API, Claude Code og Claude Cowork. Problemet blev meldt løst senere samme dag.

Andre medier beskrev også en væsentligt længere forstyrrelse 5. august, men de fremlagte kilder giver ikke et tilstrækkeligt ensartet hændelsesregister til at understøtte et præcist samlet antal Claude-nedetider i 2026. Den forsvarlige konklusion er derfor mere begrænset: Claude har været ramt af flere rapporterede forstyrrelser, men opgørelser og sammenligninger afhænger af, hvordan en hændelse defineres og dokumenteres.

Hvad betyder det for systemer i produktion?

Hændelsen 16. august illustrerer en vigtig driftsrisiko for virksomheder, der bygger på AI-API'er. Den umiddelbare fejl var autentificering – ikke et dokumenteret problem med modellens kvalitet – men en fælles adgangsafhængighed påvirkede web-, kode- og API-arbejdsgange på samme tid. En leverandør kan altså blive utilgængelig, selv om den underliggende model ikke er den direkte årsag til fejlen.

Der er ingen dokumentation i de fremlagte kilder for, at stigende brug blandt virksomheder eller forbrugere forårsagede hændelsen 16. august. Anthropic har heller ikke oplyst, at hændelsen hænger sammen med den påståede nedetid 18. august.

Sådan kan API-afhængige systemer gøres mere robuste

1. Fastlæg tilgængelighedsmål og alternativer. Behandl modelleverandøren som en ekstern afhængighed med et tydeligt SLO og en afprøvet plan for fejl.
2. Brug begrænsede genforsøg. Anvend eksponentiel backoff, tilfældig spredning, faste grænser for genforsøg og idempotens, hvor det er relevant. Undgå genforsøgsstorme under brede leverandørproblemer.
3. Forbered skift af leverandør eller model. Send egnede opgaver videre til et alternativ, men test først kompatibilitet, kvalitet, svartid, pris og krav til datahåndtering.
4. Lad systemet fungere med færre funktioner. Læg ikke-hastende opgaver i kø, gem brugerinput, understøt asynkron færdiggørelse og tilbyd en sikker nødløsning med begrænset funktionalitet.
5. Hold kritiske handlinger uafhængige. Lad ikke login, betaling, sikkerhedsovervågning eller irreversible handlinger afhænge synkront af ét LLM-kald.
6. Overvåg egne målepunkter. Følg succesrate, svartid, tid til første token, fejlkategorier, timeouts og afbrudte streams i stedet for udelukkende at stole på leverandørens statusside.
7. Øv nødskift regelmæssigt. Simulér autentificeringsfejl som 401 og 403, rate limits, 5xx-fejl, timeouts og afbrudte streaming-svar.

Den klareste konklusion er ikke, at Claude havde en bekræftet nedetid 18. august. Det er, at den verificerede hændelse 16. august viste, hvordan en kortvarig autentificeringsfejl kan brede sig på tværs af flere grænseflader – og hvorfor systemer i produktion bør være designet til at fortsætte, når én AI-leverandør bliver utilgængelig.