GitHubs stora driftstörning slog ut nedladdningar, Actions och Copilot

I en uppdatering som publicerades klockan 12.36 EDT skrev GitHub att plattformen visade tydliga tecken på återhämtning efter att företaget hade identifierat den problematiska komponenten och vidtagit åtgärder. Tjänsten var dock inte helt stabil ännu.

Återställningen skedde inte samtidigt överallt. De viktigaste plattformstjänsterna började fungera igen, medan Copilot fortfarande hade autentiseringsproblem i vissa applikationer. En sammanställning av incidenten anger att den övergripande störningen pågick till omkring 21.15 UTC, vilket innebär att den fullständiga återhämtningen tog betydligt längre tid än perioden med den mest akuta belastningen.

Hur omfattande var störningen?

GitHubs egna statusuppdateringar ger den tydligaste bilden av konsekvenserna:

• Webbupplevelsen och API-trafiken: cirka 20 procent fel.
• Arkivnedladdningar och rått repository-innehåll: cirka 50 procent fel.
• Utvecklarverktyg: Pull Requests, Issues, Actions, Webhooks, Git-operationer och Pages hade varierande grad av försämrad funktion eller otillgänglighet.
• AI-stöd för programmering: GitHub Copilot påverkades och fortsatte att vara ett aktivt problem efter att flera centrala tjänster hade återhämtat sig.
• Företagsidentitet: SAML- och OIDC-inloggning, SCIM-provisionering och Team Sync rapporterades vara påverkade. Det kunde göra det svårt för organisationer att logga in användare eller administrera deras åtkomst på ett tillförlitligt sätt.

SAML och OIDC är standarder för federerad inloggning, medan SCIM används för att automatisera skapande, uppdatering och borttagning av användarkonton. När dessa funktioner påverkas kan problemet därför märkas även om själva kodarkivet fortfarande går att nå.

Varför måndagsmorgonen förvärrade läget

Incidenten inträffade på en måndag morgon i USA, precis när många utvecklingsteam inleder arbetsveckan. Då startar ofta dagens första kodgranskningar, byggen, tester, driftsättningar och automatiserade arbetsflöden. Eftersom Actions, Pull Requests, API:er och Webhooks drabbades kunde ett team möta fel i flera sammanlänkade steg – från kodändring till leverans – i stället för i en enda avgränsad funktion.

Antalet rapporter till driftövervakningstjänster varierade beroende på tidpunkt och mätmetod. En rapport uppgav att Downdetector hade registrerat fler än 10 000 rapporter klockan 8.12 Pacific Time, medan en senare återhämtningsrapport beskrev en topp på knappt 3 000 rapporter. Sådana siffror ska inte läsas som ett exakt antal drabbade användare. De mäter inskickade rapporter och påverkas av bland annat geografi, tidpunkt och hur tjänsten samlar in data.

Vad GitHub gjorde – och vad som fortfarande är oklart

De offentliga uppdateringarna visar att GitHub:

1. utredde förhöjda fel och prestandaproblem i flera tjänster,
2. identifierade en problematisk komponent och vidtog korrigerande åtgärder,
3. fortsatte att genomföra begränsande åtgärder efter att de centrala plattformstjänsterna börjat återhämta sig, bland annat för att hantera sporadiska autentiseringsfel i Copilot.

Däremot har GitHub inte offentliggjort vilken komponent det handlade om, exakt vilken åtgärd som genomfördes eller om kapacitetsbrist orsakade just denna incident. Företaget har i bredare tillgänglighetsrapporter beskrivit hur AI-assisterad och agentbaserad utveckling driver snabbt växande trafik, men det är inte belagt att AI-belastning eller kapacitetspress var den direkta orsaken till störningen den 17 augusti.

Det slutliga svaret måste därför vänta på GitHubs utlovade postmortem, alltså en teknisk genomgång av händelseförlopp, orsak och åtgärder.

En del av ett större tillgänglighetsproblem under 2026

Augustihändelsen kom efter en skakig period. GitHubs tillgänglighetsrapport för juli dokumenterade åtta incidenter under månaden. En av dem, den 8 juli, varade i mer än sju timmar och påverkade bland annat webbgränssnittet, REST API, GraphQL API, Actions, Packages, Copilot och Git-operationer i vissa Enterprise Cloud-miljöer.

GitHub har samtidigt beskrivit en större infrastrukturell utmaning. Trafiken växer snabbt, till stor del på grund av AI-assisterade och agentbaserade utvecklingsflöden. Företagets svar har bland annat varit att flytta mer kapacitet till Azure, dela upp tjänster och minska antalet gemensamma beroenden som kan göra att ett lokalt fel sprider sig genom hela plattformen.

Skalan på planerna har också förändrats. GitHub hade ursprungligen räknat med att behöva bygga för tio gånger den dåvarande kapaciteten. I februari 2026 stod det enligt rapporteringen klart att plattformen i stället behövde dimensioneras för 30 gånger den tidigare nivån. Andra rapporter har beskrivit ytterligare kapacitet i flera moln, bland annat AWS, men dessa planer förklarar inte i sig vad som hände den 17 augusti.

Det är detta som gör incidenten viktig även utanför den enskilda förmiddagen. GitHub är inte längre bara en plats för Git-repositories. Plattformen fungerar samtidigt som samarbetsverktyg, automationsmotor, identitetstjänst och AI-baserad kodassistent. När gemensamma beroenden fallerar kan samma incident stoppa åtkomst till kod, granskningar, byggen, driftsättningar, Webhooks och kodassistans på en gång.

Vad organisationer bör ta med sig

Störningen visar inte att utvecklare står inför ett omedelbart massbyte från GitHub, och det finns inget stöd för att förutsäga en nära förestående migrationsvåg. Däremot är den en påminnelse om koncentrationsrisken för organisationer som använder GitHub genom hela leveranskedjan.

Praktiska skyddsåtgärder är bland annat att:

• ha säkerhetskopior eller speglar av repositories,
• hålla CI/CD-konfigurationer så portabla som möjligt,
• dokumentera rutiner för nödsändningar och manuella releaser,
• planera för att SSO, Webhooks eller hostade runners kan vara otillgängliga,
• se till att team vet hur de kan fortsätta arbetet utan GitHub Actions eller Copilot.

Sådana åtgärder eliminerar inte plattformsrisken, men kan minska konsekvenserna nästa gång en gemensam beroendekedja slutar fungera. Den slutliga bedömningen av den 17 augusti får vänta tills GitHub publicerar sin postmortem. Den försiktiga slutsatsen är tills vidare att GitHub drabbades av en bred och kaskaderande driftstörning, med särskilt allvarliga följder för kodnedladdningar och sammanlänkade utvecklingsflöden, och att den underliggande orsaken ännu inte är offentligt förklarad.