Výpadek GitHubu 17. srpna zasáhl stahování, Actions i Copilot. Co víme

GitHub začal vyšetřovat hlášení o zhoršeném výkonu přibližně v 13:40 UTC, tedy v 9:40 dopoledne východoamerického času (EDT) 17. srpna. Během krátké doby se problémy rozšířily na služby, které vývojáři používají k přístupu ke kódu, revizi změn, spouštění automatizace a nasazování softwaru.

Společnost později uvedla, že identifikovala problematickou komponentu a přijala nápravná opatření. Aktualizace zveřejněná ve 12:36 EDT popisovala „silné známky obnovy“, zároveň ale upozorňovala, že služba ještě není zcela stabilní.

Obnova neproběhla u všech částí platformy současně. Zatímco hlavní služby se vracely do provozu, GitHub dál řešil občasné problémy s autentizací Copilotu v některých aplikacích. Podle dalších záznamů celkový incident skončil přibližně ve 21:15 UTC, takže od prvních problémů po úplné vyřešení trval podstatně déle než samotná fáze nejzávažnějšího zhoršení výkonu.

Co všechno výpadek zasáhl?

Dopad se týkal několika vrstev GitHubu najednou:

• Web a API: přibližně 20% chybovost.
• Archivy a surový obsah repozitářů: přibližně 50% chybovost u požadavků na stažení.
• Vývojářské nástroje: omezená dostupnost nebo zhoršený výkon u pull requestů, Issues, Actions, Webhooks, Git operací a Pages.
• GitHub Copilot: služba pro AI asistenci při programování byla také zasažena a její problémy přetrvávaly i po obnovení části hlavní platformy.
• Podniková identita: hlášeny byly potíže s autentizací SAML a OIDC, zřizováním účtů přes SCIM a funkcí Team Sync. Některé organizace tak nemusely být schopny spolehlivě přihlašovat uživatele nebo spravovat jejich přístupy.

Pro týmy to znamenalo více než jen pomalejší načítání webu. Selhat mohl přístup ke zdrojovému kódu, kontrola změn, automatizované testy, webhooky spouštějící další systémy i samotné nasazení aplikace.

Kolik bylo hlášení a proč sehrálo roli pondělní ráno?

Čísla z monitorovacích služeb se lišila podle času a použité metodiky. Downdetector podle jednoho hlášení zaznamenal do 8:12 pacifického času více než 10 000 oznámení o problémech. Jiný report uváděl vrchol kolem 3 000 hlášení.

Tyto údaje nelze chápat jako přesný počet zasažených uživatelů. Downdetector počítá uživatelská hlášení, jejichž počet ovlivňuje region, čas i ochota lidí problém nahlásit.

Incident navíc začal v pondělí ráno ve Spojených státech, tedy na začátku pracovního týdne pro mnoho vývojářských týmů. Právě tehdy často startují první code review, CI/CD běhy, plánovaná nasazení a další automatizované procesy. Protože mezi zasaženými službami byly Actions, pull requesty, API i Webhooks, mohly týmy narazit na chyby v několika navazujících krocích najednou.

Co GitHub udělal a co stále nevíme

Z veřejných aktualizací lze spolehlivě vyvodit tři kroky:

1. Inženýři začali vyšetřovat zvýšenou chybovost a zhoršený výkon napříč několika službami.
2. GitHub identifikoval problematickou komponentu a přijal nápravná opatření.
3. Po obnovení hlavních služeb pokračoval v dalších mitigacích, mimo jiné kvůli občasným problémům s autentizací Copilotu.

Veřejné informace ale zatím neříkají, o jakou komponentu šlo, jak přesně náprava fungovala ani zda tento konkrétní incident způsobilo přetížení kapacity. Rychlý růst AI a agentních vývojových nástrojů patří do širší diskuse o spolehlivosti GitHubu, nelze jej však bez zveřejněné analýzy označit za potvrzenou příčinu výpadku z 17. srpna.

GitHub uvedl, že podrobná analýza kořenové příčiny bude zveřejněna později. Do té doby je nejpřesnější popis omezený: šlo o rozsáhlé kaskádové narušení několika propojených služeb, které se obnovovaly postupně.

Další kapitola v problematickém roce 2026

Srpen přišel po náročném období. GitHub ve své zprávě o dostupnosti za červenec uvedl osm incidentů. Jeden z nich, 8. července, trval více než sedm hodin a zasáhl webové rozhraní, REST API, GraphQL API, Actions, Packages, Copilot a v některých prostředích Enterprise Cloud také Git operace.

GitHub zároveň popsal širší infrastrukturní výzvu. Provoz podle společnosti rychle roste, mimo jiné kvůli vývojovým postupům podporovaným umělou inteligencí a takzvanému agentnímu vývoji, při němž AI nástroje samostatně provádějí více kroků v pracovním procesu. Mezi oznámená opatření patří přesun větší části kapacity do Azure, oddělování služeb a omezování sdílených bodů selhání.

Výrazně se změnil také plánovaný rozsah škálování. Původní cíl zvýšit kapacitu desetkrát byl podle dostupného reportingu revidován na potřebu navrhnout systém pro 30násobek tehdejšího měřítka. Další zprávy hovořily o kombinaci Azure a dodatečné multicloudové kapacity včetně AWS. Tyto plány ale samy o sobě nevysvětlují příčinu srpnového incidentu.

Co z toho plyne pro firmy?

Výpadek není důkazem, že vývojáři začnou GitHub hromadně opouštět, a dostupná data nepodporují předpověď bezprostřední migrační vlny. Ukazují ale, jak velké riziko představuje závislost na jediné platformě.

GitHub dnes není jen úložištěm repozitářů. Funguje také jako nástroj pro spolupráci, automatizaci, nasazování, správu identity a AI asistenci při programování. Selhání sdílených závislostí proto může současně přerušit přístup ke kódu, revize, buildy, releasy, webhooky i pomoc Copilotu.

Organizace závislé na GitHubu pro produkční dodávky by měly zvážit zejména:

• pravidelné zálohy nebo zrcadlení repozitářů,
• přenositelné konfigurace CI/CD,
• zdokumentované nouzové postupy pro vydání nové verze,
• připravený režim pro případ nedostupného SSO, webhooků nebo hostovaných runnerů.

Tato opatření platformové riziko neodstraní, mohou ale zmenšit dopad dalšího výpadku. Konečné hodnocení incidentu z 17. srpna bude záviset na slíbeném postmortemu. Do té doby je jisté především to, že GitHub utrpěl rozsáhlý výpadek propojených služeb, nejhůře zasáhl stahování obsahu repozitářů a jeho příčina zůstává veřejně nevysvětlená.