GitHub-nedbrud ramte downloads, Actions og Copilot – det ved vi

GitHub begyndte at undersøge meldinger om problemer med ydeevnen omkring 13.40 UTC – svarende til kl. 9.40 EDT – den 17. august. Problemerne bredte sig hurtigt til de tjenester, udviklere bruger til at hente kode, gennemgå ændringer, køre automatisering og levere software.

Senere oplyste GitHub, at selskabet havde identificeret den berørte komponent og iværksat korrigerende handlinger. I en opdatering kl. 12.36 EDT skrev GitHub, at platformen viste tydelige tegn på bedring, selv om driften endnu ikke var fuldt stabiliseret.

Genopretningen skete ikke på én gang. De vigtigste tjenester vendte tilbage til normal drift, mens Copilot fortsat havde problemer med godkendelse i visse applikationer. Andre hændelsesregistreringer angiver, at det samlede driftsstop først var afsluttet omkring 21.15 UTC, hvilket gør hændelsen betydeligt længere end den indledende periode med de mest alvorlige problemer.

Hvor omfattende var nedbruddet?

GitHubs egne fejlprocenter giver det tydeligste billede af omfanget:

• Weboplevelsen og API-trafikken: cirka 20 procent fejl.
• Arkivdownloads og råt repository-indhold: cirka 50 procent fejl.
• Udviklertjenester: Pull Requests, Issues, Actions, Webhooks, Git-operationer og Pages var på forskellige tidspunkter forringede eller utilgængelige.
• AI-baseret kodehjælp: GitHub Copilot var påvirket og var fortsat et aktivt problem, efter at flere kernetjenester var kommet sig.
• Virksomhedsidentitet: Meldinger pegede på problemer med SAML- og OIDC-login, SCIM-klargøring af brugere samt Team Sync. Det kunne gøre det vanskeligt for organisationer at logge brugere ind og administrere adgange pålideligt.

Tallene beskriver fejlprocenter – ikke andelen af alle GitHub-brugere, der mistede adgangen. En API-fejlprocent på 20 betyder derfor ikke, at præcis 20 procent af kunderne var offline. Tilsvarende gælder tallet på 50 procent kun de berørte downloadforespørgsler og ikke al trafik til repositories.

Hvorfor mandag morgen gjorde situationen værre

Hændelsen begyndte mandag morgen i USA, samtidig med at mange udviklingsteams tog hul på arbejdsugen. Det tidspunkt er vigtigt, fordi kildekodeadgang, kodegennemgange, continuous integration og automatiserede deployment-processer ofte indgår i dagens første arbejdsgange.

Actions, Pull Requests, API’er og Webhooks var blandt de berørte tjenester. Derfor kunne teams opleve fejl i flere sammenkoblede trin – eksempelvis både i en kodegennemgang, en automatiseret testkørsel og en efterfølgende deployment – i stedet for i én isoleret funktion.

Antallet af meldinger på driftsstop-trackere varierede også efter tidspunkt og tjeneste. Én rapport angav mere end 10.000 Downdetector-meldinger kl. 8.12 Pacific Time, mens en anden beskrev en top på knap 3.000 meldinger. Tallene bør ikke læses som et præcist antal berørte brugere. Sådanne tjenester tæller indsendte meldinger, og resultaterne påvirkes blandt andet af geografi, tidspunkt og målemetode.

Hvad gjorde GitHub – og hvad har selskabet ikke forklaret?

GitHubs offentlige opdateringer dokumenterer tre centrale dele af håndteringen:

1. Ingeniører undersøgte forhøjede fejl- og ydeevneproblemer på tværs af flere tjenester.
2. Selskabet identificerede en problematisk komponent og iværksatte korrigerende handlinger.
3. GitHub fortsatte med at gennemføre afhjælpende tiltag, efter at de primære platformstjenester var begyndt at komme sig. Det omfattede blandt andet sporadiske godkendelsesfejl i Copilot.

Den tilgængelige dokumentation identificerer ikke komponenten, beskriver ikke den præcise ændring, der blev foretaget, og beviser ikke, at kapacitetspres var årsagen til netop denne hændelse. Vækst i AI-relateret trafik og begrænsninger i infrastrukturen indgår i GitHubs bredere arbejde med driftsstabilitet, men bør ikke fremstilles som den bekræftede rodårsag til august-nedbruddet, før den lovede analyse er offentliggjort.

En del af et større stabilitetsproblem i 2026

August-hændelsen kom efter en vanskelig periode for GitHub. Selskabets tilgængelighedsrapport for juli dokumenterede otte hændelser i løbet af måneden. En hændelse den 8. juli varede mere end syv timer og ramte blandt andet Web UI, REST API, GraphQL API, Actions, Packages, Copilot og Git-operationer i visse Enterprise Cloud-miljøer.

GitHub har samtidig beskrevet en større infrastrukturel udfordring. I selskabets egne opdateringer hedder det, at trafikken vokser hurtigt, i betydelig grad drevet af AI-assisterede og agentbaserede udviklingsarbejdsgange. De annoncerede svar omfatter mere kapacitet i Azure, en opdeling af tjenesterne og færre fælles fejlpunkter.

Størrelsen på den planlagte udvidelse er bemærkelsesværdig. GitHubs oprindelige mål om at øge kapaciteten ti gange blev ifølge rapporteringen ændret til et behov for at kunne håndtere 30 gange den daværende skala. Andre rapporter har beskrevet planer om yderligere kapacitet på tværs af flere cloudmiljøer, herunder AWS, men disse planer forklarer ikke i sig selv august-hændelsen.

Det gør nedbruddet relevant ud over den enkelte morgen. GitHub er ikke kun et sted at gemme Git-repositories. Platformen fungerer også som samarbejdslag, automatiseringsplatform, identitetssystem og AI-baseret kodningsværktøj. Når fælles afhængigheder svigter, kan én hændelse derfor afbryde repository-adgang, kodegennemgange, builds, deployments, Webhooks og kodeassistance på samme tid.

Hvad bør organisationer lære af hændelsen?

Nedbruddet beviser ikke, at udviklere er på vej væk fra GitHub, og der er ikke belæg for at forudsige en nært forestående masseflytning til andre platforme. Hændelsen viser dog, hvorfor organisationer, der bruger GitHub til produktionsleverancer, bør gennemgå deres antagelser om, hvad der sker, når platformen svigter.

Praktiske tiltag kan være at:

• vedligeholde sikkerhedskopier eller spejle af repositories,
• holde CI/CD-konfigurationer flytbare mellem platforme,
• dokumentere nødprocedurer for releases,
• sikre, at teams ved, hvordan de arbejder, hvis SSO, Webhooks eller hostede runners ikke er tilgængelige.

Tiltagene fjerner ikke platformrisikoen, men de kan begrænse konsekvenserne ved det næste driftsstop.

Den endelige vurdering af 17. august afhænger af GitHubs postmortem. Indtil den foreligger, er den mest holdbare konklusion mere afgrænset: GitHub oplevede en bred, kaskaderende driftsforstyrrelse med alvorlige problemer for repository-downloads og sammenkoblede udviklerarbejdsgange. Tjenesterne kom tilbage i etaper, men den underliggende fejl er endnu ikke offentligt forklaret.