GitHub var nede i næsten 8 timer den 17. august
GitHub.com oplevede et nedbrud på 7 timer og 47 minutter den 17. august 2026, fra kl. 13:28 til 21:15 UTC, som forringede stort set alle centrale udviklerworkflows på platformen. Forhøjede fejlrater og latenstider ramte samtidig Issues, Pull Requests, REST- og GraphQL-API'erne, GitHub Actions og GitHub Copilot, så forstyrrelsen ikke var begrænset til én funktion. GitHubs eget postmortem, offentliggjort på github.blog under titlen "The August 17 outage and the work ahead", angiver en maksimal fejlrate på omkring 20% site-bredt, og omkring 50% specifikt for arkiv- og raw-fildownloads. The Register, TechTimes og dev.to bekræftede tidslinje og omfang i deres egen dækning af hændelsen.
| Måltal | Værdi |
|---|---|
| Start (UTC) | 13:28 |
| Slut (UTC) | 21:15 |
| Varighed | 7 timer 47 minutter |
| Maksimal fejlrate, site-bredt | ~20% |
| Maksimal fejlrate, arkiv/raw-downloads | ~50% |
Årsagen var en proxy på sin grænse, ikke en fejlslagen deployment
GitHubs postmortem fastslår klart, at nedbruddet ikke skyldtes en kode- eller konfigurationsdeployment; det var en kapacitets- og overvågningsfejl i selskabets egen netværksinfrastruktur. Udløseren var en Istio service-mesh sidecar-proxy i et datacenter i Central US, som ramte sin concurrency-grænse, da trafikken ankom i et nyt spidsmønster, som systemet ikke var dimensioneret til. En service-mesh sidecar sidder ved siden af hver serviceinstans for at styre dens netværkstrafik, så når en rammer et hårdt loft under uventet belastning, fejler alt, der routes gennem den, på én gang i stedet for gradvist at forringes.
En fejlkonfigureret alarm betød, at ingen så det komme
En intern overvågningspolitik var fejlkonfigureret og advarede ikke GitHubs ingeniører, da sidecar-proxyen nærmede sig sin concurrency-grænse, så den alarm, der skulle have udløst en reaktion, før brugerne bemærkede noget, udeblev simpelthen. Det hul betyder lige så meget som selve concurrency-grænsen: en kapacitetsgrænse, der fanges tidligt, er en stille opgradering, en grænse, der først fanges efter brugerne ser fejl, bliver en hændelse på flere timer. GitHub siger, at lukningen af det overvågningshul er en del af det "work ahead", der refereres til i postmortemets titel.
GitHubs egen retry-logik, især fra VS Code, gjorde det værre
Optimistisk klient-side retry-logik i hele GitHubs økosystem gjorde en overbelastet proxy til en kaskade, der ramte hele platformen, og GitHub udpegede en retry-storm fra VS Code-klienter som en væsentlig årsag til, hvor slemt nedbruddet blev. Når en forespørgsel fejler, og en klient straks prøver igen uden at vente, fejler den ikke bare igen, den lægger endnu en forespørgsel oven i et allerede overbelastet system, og ganget med millioner af VS Code-installationer, der tjekker ind hos GitHub i baggrunden, gjorde det mønster et afgrænset proxyproblem til et platformbredt problem. Det er den detalje, der gør hændelsen til mere end en historie om GitHubs infrastruktur; det bliver en historie om, hvordan enhver klient til enhver API bør bygges.
For enhver virksomhed med pipeline gennem GitHub var dette et 8-timers black-out
De fleste virksomheder tænker på et GitHub-nedbrud som en gene for udviklere, noget man brokker sig over, mens man venter, men for enhver virksomhed, der stille og roligt har gjort GitHub Actions og Copilot til en del af sin release-pipeline, er 7 timer og 47 minutter uden GitHub 7 timer og 47 minutter, hvor man ikke kan udsende en hotfix, ikke kan merge et sikkerhedspatch og, hvis Copilot er en del af workflowet, mister et AI-assisteret kodningsværktøj midt i en opgave. Det er en koncentrationsrisiko på én leverandør gemt inde i det, der ligner "bare at bruge GitHub", og det dukker ikke op på nogen budgetlinje, som et softwareabonnement ville. Den skarpere lektie er retry-stormen: hvis GitHubs egen klientsoftware gjorde et nedbrud værre ved at prøve aggressivt igen uden at vente, bør enhver virksomhed, der bygger sine egne systemer mod tredjeparts-API'er, gennemgå sin egen retry-logik for samme fejlmønster i stedet for at arkivere det som udelukkende GitHubs problem.
Læs videre: Wiz' AI-Agent Hackede Snowflake og Beskyldte Copilot | Din Anden Git-Vært Tændte Sig Selv
