GitHub låg nere i nästan 8 timmar den 17 augusti
GitHub.com drabbades av ett driftstopp på 7 timmar och 47 minuter den 17 augusti 2026, från 13:28 till 21:15 UTC, som försämrade nästan alla centrala utvecklarflöden på plattformen. Förhöjda felfrekvenser och latens drabbade samtidigt Issues, Pull Requests, REST- och GraphQL-API:erna, GitHub Actions och GitHub Copilot, så störningen var inte begränsad till en enda funktion. GitHubs egen postmortem, publicerad på github.blog under titeln "The August 17 outage and the work ahead", anger en toppfelfrekvens på runt 20% site-brett, och runt 50% specifikt för arkiv- och raw-filnedladdningar. The Register, TechTimes och dev.to bekräftade tidslinjen och omfattningen i sin egen rapportering om händelsen.
| Mätvärde | Värde |
|---|---|
| Start (UTC) | 13:28 |
| Slut (UTC) | 21:15 |
| Varaktighet | 7 timmar 47 minuter |
| Toppfelfrekvens, site-brett | ~20% |
| Toppfelfrekvens, arkiv/raw-nedladdningar | ~50% |
Orsaken var en proxy vid sin gräns, inte en misslyckad driftsättning
GitHubs postmortem slår tydligt fast att driftstoppet inte orsakades av en kod- eller konfigurationsdriftsättning; det var ett kapacitets- och övervakningsfel inom företagets egen nätverksinfrastruktur. Utlösaren var en Istio service mesh-sidecar-proxy i ett datacenter i Central US som nådde sin concurrency-gräns när trafiken kom in i ett nytt toppmönster som systemet inte var dimensionerat för. En service mesh-sidecar sitter bredvid varje tjänsteinstans för att hantera dess nätverkstrafik, så när en når ett hårt tak under oväntad belastning fallerar allt som routas genom den på en gång i stället för att gradvis försämras.
En felkonfigurerad larmregel gjorde att ingen såg det komma
En intern övervakningspolicy var felkonfigurerad och larmade inte GitHubs ingenjörer när sidecar-proxyn närmade sig sin concurrency-gräns, så larmet som skulle ha utlöst en åtgärd innan användarna märkte något gick helt enkelt aldrig av. Den luckan väger lika tungt som själva concurrency-gränsen: en kapacitetsgräns som upptäcks tidigt är en tyst uppgradering, en gräns som upptäcks först efter att användare ser fel blir en flera timmar lång incident. GitHub säger att åtgärdandet av den övervakningsluckan är en del av det "work ahead" som nämns i postmortemets titel.
GitHubs egen retry-logik, särskilt från VS Code, gjorde det värre
Optimistisk klientsidig retry-logik i hela GitHubs ekosystem förvandlade en överbelastad proxy till en kaskad som drabbade hela plattformen, och GitHub pekade ut en retry-storm från VS Code-klienter som en viktig orsak till hur illa driftstoppet blev. När en förfrågan misslyckas och en klient direkt försöker igen utan att vänta, misslyckas den inte bara igen, den lägger till ytterligare en förfrågan till ett redan överbelastat system, och multiplicerat över miljontals VS Code-installationer som pingar GitHub i bakgrunden förvandlade det mönstret ett avgränsat proxyproblem till ett plattformsbrett. Det är detaljen som gör incidenten till mer än en historia om GitHubs infrastruktur; den blir en historia om hur varje klient till varje API borde byggas.
För varje företag med sin pipeline via GitHub var detta ett 8 timmar långt avbrott
De flesta företag ser ett GitHub-driftstopp som ett irritationsmoment för utvecklare, något man klagar på medan man väntar, men för varje företag som tyst har gjort GitHub Actions och Copilot till en del av sin release-pipeline är 7 timmar och 47 minuter utan GitHub 7 timmar och 47 minuter då man varken kan leverera en hotfix eller merga en säkerhetspatch, och, om Copilot är en del av arbetsflödet, förlorar ett AI-assisterat kodningsverktyg mitt i en uppgift. Det är en koncentrationsrisk på en enda leverantör dold inuti det som ser ut som att "bara använda GitHub", och den syns inte på någon budgetrad så som en mjukvaruprenumeration skulle göra. Den skarpare lärdomen är retry-stormen: om GitHubs egen klientmjukvara gjorde ett driftstopp värre genom att aggressivt försöka igen utan att vänta, borde varje företag som bygger egna system mot tredjeparts-API:er granska sin egen retry-logik efter samma felmönster, i stället för att arkivera det som enbart GitHubs problem.
Läs vidare: Wiz' AI-Agent Hackade Snowflake och Skyllde på Copilot | Din Andra Git-Värd Slog På Sig Själv
