Za tři měsíce 96 hlášení o poruchách u OpenAI. Příčinu popisuje jediné z nich
Stavovou stránku OpenAI jsme přečetli strojově, ne okem: od května do konce července 2026 na ní přibylo 96 záznamů o poruchách. Příčinu z nich popisuje jediný, osmdesát osm se zavírá doslova stejnou větou. Dostupnost v procentech přitom u OpenAI i u Anthropicu mluví o jednotkách hodin za celé čtvrtletí.

Když poskytovateli jazykových modelů něco přestane fungovat, zákazník se to dozví ze stavové stránky. Je to jediný veřejný záznam o dostupnosti služby a dá se přečíst strojově. Prošli jsme proto historii OpenAI a Anthropicu za květen až červenec 2026 a spočítali, kolik hlášení v ní je, jak dlouho zůstávají otevřená a co se z nich čtenář dozví.
Devadesát šest hlášení za jedenadevadesát dnů
Přehled historie OpenAI obsahuje za ty tři měsíce 96 záznamů: 31 v květnu, 30 v červnu a 35 v červenci do třicátého dne včetně. Aspoň jedno hlášení připadá na 61 dnů z 91, tedy na dva dny ze tří. Nepočítali jsme to okem – čísla vycházejí ze zdrojového kódu stránky staženého 31. července 2026, protože ruční počítání položek v dlouhém výpisu dá pokaždé jiný výsledek.
Anthropic počet u každého měsíce uvádí sám na tlačítku, kterým se výpis rozbaluje: 41 za květen, 47 za červen a 54 za červenec. Přepočítat jsme si je nemohli, protože rozbalené položky se do stránky dotahují až kliknutím. Postavit ta čísla proti počtu OpenAI by stejně nešlo. Každá firma zakládá záznamy jinak: OpenAI je vede po produktech (ChatGPT, API, Codex), Anthropic po modelech, takže se v jeho výpisu opakují hlášení lišící se jen jménem modelu. Jen 27. července má tři samostatné záznamy o chybách modelu Opus 5 – a z veřejných dat se nedá zjistit, jestli za nimi byla jedna příčina, nebo tři.
Osmaosmdesátkrát doslova táž věta
Stáhli jsme všech 96 stránek jednotlivých hlášení OpenAI i s celým průběhem aktualizací a prohledali je na formulace, kterými se popisuje příčina – „root cause“, „caused by“, „due to“, „deploy“, „rollback“, „regression“ a podobně. Vyhovělo jediné hlášení z devadesáti šesti: záznam z 8. května o chybách 404 v rozhraní Responses API, který končí větou, že firma potíž vyhodnotila jako důsledek nedávného nasazení a to nasazení vrátila zpět.
Zbylých 95 příčinu neuvádí. Osmdesát osm z nich se zavírá doslova stejnou větou: „All impacted services have now fully recovered.“ Tedy že se zasažené služby plně zotavily. Nic o tom, co se pokazilo.
Nepomůže ani stav „identified“, který v průběhu hlášení vypadá jako okamžik, kdy se na příčinu přišlo. U pětadvaceti hlášení dostupných přes rozhraní jsme přečetli všech 105 aktualizací a nejčastější text stavu „identified“ zní: „We have identified that users are experiencing elevated errors for the impacted services.“ Zjištěním je tu tedy to, že uživatelům chodí chyby. U Anthropicu je to podobné: v padesáti nejnovějších záznamech, které jeho rozhraní vydává, se v 18 případech opakuje „The issue has been identified and a fix is being implemented“, a příčinu nejmenuje žádný.
Otevřený záznam není délka výpadku
Rozhraní obou firem vrací čas vzniku a uzavření, takže se dá spočítat, jak dlouho byl otevřený aspoň jeden záznam. Pro shodné okno od 15. do 30. července 2026, tedy 384 hodin, vychází u OpenAI 135 hodin (35 % času) a u Anthropicu 99 hodin (26 %). Intervaly jsme sjednotili, ne sečetli; prostý součet by u překrývajících se hlášení nadsadil.
Ta čísla ale neznamenají, že služba třetinu měsíce nefungovala. Nejdelší hlášení OpenAI v tom okně vzniklo 25. července ve 22:09 a zavřelo se 27. července v 16:32, tedy po 42 hodinách a 23 minutách – jenže stav „monitoring“ s poznámkou o nasazeném zmírnění je z 25. července z 23:57. Záznam tak zůstal otevřený zhruba čtyřicet hodin poté, co firma ohlásila nápravu. Opačný případ je jediné hlášení označené jako kritické: potíž s hlasovým režimem ChatGPT 15. července trvala podle časových značek 87 sekund.
Jeden záznam si přitom odporuje sám. U hlášení o zvýšené latenci modelů gpt 5.1 mini a gpt 4.1 mini z 27. července uvádí rozhraní čas vzniku 18:06 a čas uzavření 17:30, tedy o 36 minut dřív. Poslední aktualizace téhož hlášení je přitom z 20:52. Pole s časem uzavření se tu tedy neshoduje ani s vlastním průběhem hlášení, natož s realitou.
Procenta mluví o hodinách, historie o desítkách dnů
Vedle výpisu poruch zveřejňují obě firmy i dostupnost v procentech. OpenAI uvádí za květen až červenec u ChatGPT 99,66 %, u API 99,93 %, u Codexu 99,98 % a u prostředí FedRAMP rovných 100 %. Anthropic vykazuje claude.ai po měsících: 99,49 % v květnu, 99,54 % v červnu a 99,01 % v červenci.
Přepočteno na čas – což je náš výpočet, na stránkách to takhle nestojí – vychází u ChatGPT z 2 184 hodin toho čtvrtletí zhruba 7,4 hodiny nedostupnosti a u claude.ai za samotný červenec asi 7 hodin ze 720. Proti dvěma třetinám dnů s otevřeným hlášením je to jiný svět. Rozpor to není: hlášení „elevated error rates“ znamená, že části požadavků se vracely chyby, ne že služba stála. Pod tabulkou dostupnosti to OpenAI říká vlastními slovy – údaje jsou agregát přes všechny tarify, modely a typy chyb a dostupnost, kterou zažil konkrétní zákazník, se od nich může lišit.
Pro provoz z toho plyne nepříjemný závěr: jedno číslo je průměr přes celou zákaznickou základnu, druhé měří dobu, po kterou byl otevřený lísteček. Ani z jednoho se nedá zjistit, jak dlouho byla služba nepoužitelná zrovna pro vás.
Do minulosti rozhraní nevidí
Strojové rozhraní OpenAI (/api/v2/incidents.json) vrátilo 25 nejnovějších hlášení, tedy šestnáct dnů zpětně; parametry ?page=2 a ?per_page=100 na tom nic nezmění, odpověď je pokaždé stejná. Rozhraní Anthropicu vydá 50 záznamů, což bylo k 31. červenci 25 dnů. Delší řadu nabízí jen webová stránka, a to na tři měsíce zpět.
Server The Next Web napočítal 25. července asi 166 incidentů OpenAI za zhruba devět měsíců, tedy kolem osmnácti měsíčně. Z našeho počtu za poslední tři měsíce vychází dvaatřicet měsíčně. Rozpor to nemusí být, jde o jiná období – ověřit to ale nejde, protože do doby před květnem se veřejně nedostanete. Tentýž text uvádí, že agentní produkty OpenAI překročily deset milionů týdenních uživatelů; právě u agenta, který uprostřed vícekrokové úlohy narazí na chybu, je rozdíl mezi „chvíli to házelo chyby“ a „nefungovalo to“ podstatný.
Co by stačilo
Podle nás nejde o to, že by poskytovatelé měli mít méně poruch. Jde o to, že záznam o poruše může nést tři údaje, které dnes nenese: co ji způsobilo, jak dlouho trvala doopravdy a koho se týkala. Osmdesát osm stejných vět po sobě není hlášení o dostupnosti, je to potvrzení, že se něco stalo a už se to neděje. Jediné hlášení z devadesáti šesti ukazuje, že to jde napsat jinak – stačila na to jedna věta o vráceném nasazení.
Zdroje: historie stavů OpenAI a její rozhraní incidents.json, dostupnost OpenAI, historie stavů Claude a dostupnost claude.ai, The Next Web. Data stažena 31. července 2026.