Žádný ověřený výpadek Claude 18. srpna. Skutečný incident přišel o dva dny dříve

Časová osa

• 16. srpna, 21:58 UTC: Anthropic začal prověřovat potíže s autentizací, které postihly část uživatelů.
• Krátce poté: Incident se rozšířil na zhoršený výkon dalších služeb Claude.
• 22:34 UTC: Anthropic označil zasažené služby za obnovené.

Kolik hlášení zaznamenal Downdetector?

Média informující o výpadku ze 16. srpna uváděla, že počet hlášení na Downdetectoru přesáhl 15 000. Toto číslo je ale nutné číst s rezervou. Downdetector shromažďuje hlášení od uživatelů; neměří skutečný počet zasažených zákazníků, neúspěšných API požadavků ani délku výpadku u jednotlivých lidí.

V dodaných podkladech není spolehlivý zdroj, který by potvrzoval konkrétní počet hlášení Downdetectoru pro výpadek Anthropic 18. srpna. Údaj o více než 15 000 hlášeních proto nelze k tomuto datu přiřazovat.

Proč výpadek silně pocítili uživatelé Claude Code

Claude Code patřil mezi zasažené služby. Pro vývojáře proto nešlo jen o pomalejší nebo nedokončenou odpověď chatbota. Pokud se kódovací nástroj nedokáže autentizovat, uživatel nemusí být schopen zahájit relaci, navázat na rozpracovaný úkol nebo se dostat k práci v terminálu či editoru.

To vysvětluje, proč mohou být poruchy autentizace v programátorském prostředí obzvlášť citelné: zablokují celý pracovní postup hned na jeho začátku. Dostupné podklady ale nepotvrzují samostatný, specifický typ poruchy Claude Code ani neuvádějí počet stížností uživatelů Claude Code z 18. srpna.

Srovnání s dalšími incidenty v roce 2026

Událost ze 16. srpna byla relativně krátká, současně však zasáhla několik produktových rozhraní. Samostatný incident z 12. srpna se týkal zvýšeného počtu chyb u více modelů Claude a zhoršeného výkonu služeb claude.ai, Claude API, Claude Code a Claude Cowork; později téhož dne byl označen za vyřešený.

Další zprávy popisovaly výrazně delší narušení provozu 5. srpna. Dodané zdroje však neposkytují dostatečně konzistentní záznamy, aby z nich bylo možné spolehlivě odvodit přesný počet výpadků Claude v roce 2026. Obhajitelný závěr je užší: Claude čelil několika hlášeným poruchám, ale jejich počet i vzájemné srovnání závisí na tom, jak se incidenty definují a dokumentují.

Co incident znamená pro produkční systémy

Výpadek ze 16. srpna ukazuje důležité riziko pro týmy, které stavějí na AI API. Bezprostředním problémem byla autentizace, nikoli doložená změna kvality modelu. Přesto jediná sdílená přístupová závislost současně ovlivnila web, vývojářské nástroje i API.

Poskytovatel tak může být pro uživatele nedostupný, i když samotný model není přímým zdrojem poruchy. V dostupných podkladech není důkaz, že by incident ze 16. srpna způsobilo rostoucí využití ze strany firem nebo spotřebitelů. Anthropic rovněž nezveřejnil spojitost mezi touto událostí a údajným výpadkem z 18. srpna.

Jak omezit dopad výpadku AI API

1. Stanovte cíle dostupnosti a záložní postupy. Na poskytovatele modelu pohlížejte jako na externí závislost s jasně definovaným SLO a otestovaným plánem pro případ selhání.
2. Používejte omezené opakování požadavků. Nastavte exponenciální prodlevu, náhodné rozložení opakování, pevný limit pokusů a podle potřeby také idempotenci. Během rozsáhlého incidentu se vyhněte nekontrolovaným smyčkám opakování.
3. Připravte přepnutí na jiného poskytovatele nebo model. Vhodnou práci směrujte jinam až po otestování kompatibility promptů, kvality, latence, nákladů a požadavků na nakládání s daty.
4. Navrhněte řízené omezení funkcí. Neurgentní úlohy zařaďte do fronty, uchovejte uživatelský vstup, nabídněte asynchronní dokončení a připravte bezpečný režim s omezenou funkcionalitou.
5. Držte kritické operace mimo jediný požadavek LLM. Autentizace, platby, bezpečnostní monitoring ani nevratné akce by neměly synchronně záviset na jednom volání jazykového modelu.
6. Sledujte vlastní telemetrii. Měřte úspěšnost požadavků, latenci, čas do prvního tokenu, typy chyb, timeouty a přerušené streamování. Nespoléhejte pouze na statusovou stránku poskytovatele.
7. Pravidelně procvičujte přepnutí. Simulujte chyby autentizace 401 a 403, limity 429, chyby 5xx, timeouty i přerušené streamované odpovědi.

Nejjasnější závěr tedy nezní, že Claude měl potvrzený výpadek 18. srpna. Ověřený incident ze 16. srpna ukázal, jak může krátká porucha autentizace zasáhnout několik rozhraní najednou — a proč by produkční systémy měly umět fungovat i ve chvíli, kdy je jeden poskytovatel AI nedostupný.