Tidslinjen: fra gransking til gradvis gjenoppretting

GitHub begynte å undersøke rapporter om ytelsesproblemer rundt 13.40 UTC, tilsvarende 09.40 EDT, 17. august. Forstyrrelsen spredte seg raskt til tjenester utviklere bruker for å hente kode, gjennomgå endringer, kjøre automatisering og levere programvare.

I en oppdatering publisert klokken 12.36 EDT skrev GitHub at selskapet hadde identifisert den berørte komponenten og iverksatt korrigerende tiltak. Plattformen viste da tydelige tegn til bedring, men var ikke fullt stabilisert.

Gjenopprettingen skjedde ikke samtidig overalt. GitHubs statusrapportering viste at flere sentrale tjenester var tilbake i drift, mens Copilot fortsatt hadde autentiseringsproblemer i enkelte applikasjoner. Andre hendelsesrapporter satte slutten på den samlede forstyrrelsen til rundt 21.15 UTC. Det betyr at hele hendelsen varte betydelig lenger enn perioden med den kraftigste forverringen.

Hvor omfattende var problemene?

De tydeligste målene på omfanget var feilratene GitHub selv rapporterte:

• Nettopplevelsen og API-trafikken: omtrent 20 prosent feil.
• Arkivnedlastinger og rått repository-innhold: omtrent 50 prosent feil.
• Utviklerverktøy: Pull Requests, Issues, Actions, Webhooks, Git-operasjoner og Pages var svekket eller utilgjengelige på ulike tidspunkter.
• AI-basert kodehjelp: GitHub Copilot ble rammet og var fortsatt et aktivt problem etter at flere kjernetjenester var tilbake.
• Bedriftsidentitet: Rapporter viste forstyrrelser i SAML- og OIDC-autentisering, SCIM-klargjøring og Team Sync. Det kunne gjøre det vanskelig for organisasjoner å logge inn brukere eller administrere tilganger pålitelig.

Tallene beskriver feilrater, ikke hvor stor andel av alle GitHub-brukere som mistet tilgangen. En API-feilrate på 20 prosent betyr ikke at nøyaktig 20 prosent av kundene var koblet fra. Tilsvarende gjelder 50-prosenttallet bare de berørte nedlastingsforespørslene, ikke all trafikk til repositories.

Hvorfor mandag morgen gjorde situasjonen verre

Hendelsen startet mandag morgen i USA, samtidig som mange utviklingsteam begynner arbeidsuken. Det er ofte tidspunktet for dagens første kodegjennomganger, bygg og tester, utrullinger og planlagte automatiserte arbeidsflyter.

Siden Actions, Pull Requests, API-er og Webhooks var blant tjenestene som ble rammet, kunne team møte feil i flere sammenkoblede deler av utviklingsprosessen samtidig – ikke bare i én enkelt funksjon.

Også tallene fra tjenester som registrerer driftsproblemer varierte med tidspunkt og målemetode. Én rapport viste mer enn 10 000 meldinger til Downdetector innen klokken 08.12 Pacific Time, mens en annen rapport om gjenopprettingen viste en topp på nær 3 000 meldinger. Dette bør ikke tolkes som et nøyaktig antall berørte brukere. Slike tjenester teller innsendte meldinger, og tallene påvirkes av geografi, tidspunkt og hvordan rapportene samles inn.

Hva GitHub gjorde – og hva selskapet ikke har forklart

De offentlige oppdateringene dokumenterer tre hoveddeler av håndteringen:

1. Ingeniørene undersøkte forhøyede feil- og ytelsesproblemer i flere tjenester.
2. Selskapet identifiserte en problematisk komponent og iverksatte korrigerende tiltak.
3. GitHub fortsatte med avbøtende tiltak etter at de viktigste plattformtjenestene begynte å komme tilbake, blant annet for sporadiske autentiseringsfeil i Copilot.

Det tilgjengelige materialet identifiserer ikke komponenten, beskriver ikke det nøyaktige korrigerende tiltaket og beviser ikke at kapasitetsmangel forårsaket denne spesifikke hendelsen. Vekst i AI-drevet trafikk og begrensninger i infrastrukturen inngår i GitHubs bredere arbeid med stabilitet, men bør ikke omtales som den bekreftede årsaken til nedetiden 17. august før den lovede rapporten foreligger.

Del av et større stabilitetsproblem i 2026

August-hendelsen kom etter en krevende periode for GitHub. Selskapets tilgjengelighetsrapport for juli dokumenterte åtte hendelser i løpet av måneden. En hendelse 8. juli varte i mer enn sju timer og rammet blant annet Web UI, REST API, GraphQL API, Actions, Packages, Copilot og Git-operasjoner i enkelte Enterprise Cloud-miljøer.

GitHub har samtidig beskrevet en større infrastrukturutfordring. I kommunikasjonen om tilgjengelighet skrev selskapet at trafikken vokser raskt, i stor grad drevet av AI-assistert og agentbasert programvareutvikling. Tiltakene som er nevnt, omfatter å flytte mer kapasitet til Azure, dele opp tjenester og redusere antallet felles avhengigheter som kan føre til at én feil sprer seg.

Omfanget av planene er bemerkelsesverdig. GitHub hadde først et mål om å øke kapasiteten ti ganger, men kom senere frem til at infrastrukturen måtte bygges for 30 ganger den daværende skalaen. Andre rapporter har omtalt planer som involverer Azure og ytterligere kapasitet fra flere skyleverandører, blant annet AWS. Disse planene forklarer imidlertid ikke i seg selv hva som utløste august-hendelsen.

GitHub er ikke bare et sted å lagre Git-repositories. Plattformen fungerer også som samarbeidsverktøy, automatiseringsplattform, identitetssystem og AI-tjeneste for programmering. Når flere av disse funksjonene deler avhengigheter, kan én hendelse stanse tilgang til kode, gjennomganger, bygg, utrullinger, Webhooks og kodeassistanse samtidig.

Hva virksomheter bør ta med seg

Nedetiden beviser ikke at utviklere er i ferd med å forlate GitHub, og det finnes ikke grunnlag for å forutsi en nært forestående migrasjonsbølge. Den viser likevel hvorfor virksomheter som er avhengige av GitHub i produksjonsleveranser, bør gå gjennom sine antakelser om hva som skjer når plattformen svikter.

Praktiske tiltak kan være å ha sikkerhetskopier eller speil av repositories, sørge for at CI/CD-oppsett kan flyttes, dokumentere rutiner for nødutgivelser og sikre at team vet hvordan de skal arbeide når SSO, Webhooks eller vertsbaserte runners er utilgjengelige.

Slike tiltak fjerner ikke plattformrisikoen, men kan begrense skadeomfanget ved neste forstyrrelse. Den endelige vurderingen av 17. august avhenger av GitHubs postmortem. Inntil den foreligger, er den mest forsvarlige konklusjonen begrenset: GitHub opplevde en bred og kaskaderende tjenesteforstyrrelse med alvorlige konsekvenser for repository-nedlastinger og sammenkoblede utviklerarbeidsflyter. Tjenestene kom tilbake trinnvis, men den underliggende feilen er ennå ikke offentlig forklart.

Tidslinjen: fra gransking til gradvis gjenoppretting

GitHub begynte å undersøke rapporter om ytelsesproblemer rundt 13.40 UTC, tilsvarende 09.40 EDT, 17. august. Forstyrrelsen spredte seg raskt til tjenester utviklere bruker for å hente kode, gjennomgå endringer, kjøre automatisering og levere programvare.

I en oppdatering publisert klokken 12.36 EDT skrev GitHub at selskapet hadde identifisert den berørte komponenten og iverksatt korrigerende tiltak. Plattformen viste da tydelige tegn til bedring, men var ikke fullt stabilisert.

Gjenopprettingen skjedde ikke samtidig overalt. GitHubs statusrapportering viste at flere sentrale tjenester var tilbake i drift, mens Copilot fortsatt hadde autentiseringsproblemer i enkelte applikasjoner. Andre hendelsesrapporter satte slutten på den samlede forstyrrelsen til rundt 21.15 UTC. Det betyr at hele hendelsen varte betydelig lenger enn perioden med den kraftigste forverringen.

Hvor omfattende var problemene?

De tydeligste målene på omfanget var feilratene GitHub selv rapporterte:

• Nettopplevelsen og API-trafikken: omtrent 20 prosent feil.
• Arkivnedlastinger og rått repository-innhold: omtrent 50 prosent feil.
• Utviklerverktøy: Pull Requests, Issues, Actions, Webhooks, Git-operasjoner og Pages var svekket eller utilgjengelige på ulike tidspunkter.
• AI-basert kodehjelp: GitHub Copilot ble rammet og var fortsatt et aktivt problem etter at flere kjernetjenester var tilbake.
• Bedriftsidentitet: Rapporter viste forstyrrelser i SAML- og OIDC-autentisering, SCIM-klargjøring og Team Sync. Det kunne gjøre det vanskelig for organisasjoner å logge inn brukere eller administrere tilganger pålitelig.

Tallene beskriver feilrater, ikke hvor stor andel av alle GitHub-brukere som mistet tilgangen. En API-feilrate på 20 prosent betyr ikke at nøyaktig 20 prosent av kundene var koblet fra. Tilsvarende gjelder 50-prosenttallet bare de berørte nedlastingsforespørslene, ikke all trafikk til repositories.

Hvorfor mandag morgen gjorde situasjonen verre

Hendelsen startet mandag morgen i USA, samtidig som mange utviklingsteam begynner arbeidsuken. Det er ofte tidspunktet for dagens første kodegjennomganger, bygg og tester, utrullinger og planlagte automatiserte arbeidsflyter.

Siden Actions, Pull Requests, API-er og Webhooks var blant tjenestene som ble rammet, kunne team møte feil i flere sammenkoblede deler av utviklingsprosessen samtidig – ikke bare i én enkelt funksjon.

Også tallene fra tjenester som registrerer driftsproblemer varierte med tidspunkt og målemetode. Én rapport viste mer enn 10 000 meldinger til Downdetector innen klokken 08.12 Pacific Time, mens en annen rapport om gjenopprettingen viste en topp på nær 3 000 meldinger. Dette bør ikke tolkes som et nøyaktig antall berørte brukere. Slike tjenester teller innsendte meldinger, og tallene påvirkes av geografi, tidspunkt og hvordan rapportene samles inn.

Hva GitHub gjorde – og hva selskapet ikke har forklart

De offentlige oppdateringene dokumenterer tre hoveddeler av håndteringen:

1. Ingeniørene undersøkte forhøyede feil- og ytelsesproblemer i flere tjenester.
2. Selskapet identifiserte en problematisk komponent og iverksatte korrigerende tiltak.
3. GitHub fortsatte med avbøtende tiltak etter at de viktigste plattformtjenestene begynte å komme tilbake, blant annet for sporadiske autentiseringsfeil i Copilot.

Det tilgjengelige materialet identifiserer ikke komponenten, beskriver ikke det nøyaktige korrigerende tiltaket og beviser ikke at kapasitetsmangel forårsaket denne spesifikke hendelsen. Vekst i AI-drevet trafikk og begrensninger i infrastrukturen inngår i GitHubs bredere arbeid med stabilitet, men bør ikke omtales som den bekreftede årsaken til nedetiden 17. august før den lovede rapporten foreligger.

Del av et større stabilitetsproblem i 2026

August-hendelsen kom etter en krevende periode for GitHub. Selskapets tilgjengelighetsrapport for juli dokumenterte åtte hendelser i løpet av måneden. En hendelse 8. juli varte i mer enn sju timer og rammet blant annet Web UI, REST API, GraphQL API, Actions, Packages, Copilot og Git-operasjoner i enkelte Enterprise Cloud-miljøer.

GitHub har samtidig beskrevet en større infrastrukturutfordring. I kommunikasjonen om tilgjengelighet skrev selskapet at trafikken vokser raskt, i stor grad drevet av AI-assistert og agentbasert programvareutvikling. Tiltakene som er nevnt, omfatter å flytte mer kapasitet til Azure, dele opp tjenester og redusere antallet felles avhengigheter som kan føre til at én feil sprer seg.

Omfanget av planene er bemerkelsesverdig. GitHub hadde først et mål om å øke kapasiteten ti ganger, men kom senere frem til at infrastrukturen måtte bygges for 30 ganger den daværende skalaen. Andre rapporter har omtalt planer som involverer Azure og ytterligere kapasitet fra flere skyleverandører, blant annet AWS. Disse planene forklarer imidlertid ikke i seg selv hva som utløste august-hendelsen.

GitHub er ikke bare et sted å lagre Git-repositories. Plattformen fungerer også som samarbeidsverktøy, automatiseringsplattform, identitetssystem og AI-tjeneste for programmering. Når flere av disse funksjonene deler avhengigheter, kan én hendelse stanse tilgang til kode, gjennomganger, bygg, utrullinger, Webhooks og kodeassistanse samtidig.

Hva virksomheter bør ta med seg

Nedetiden beviser ikke at utviklere er i ferd med å forlate GitHub, og det finnes ikke grunnlag for å forutsi en nært forestående migrasjonsbølge. Den viser likevel hvorfor virksomheter som er avhengige av GitHub i produksjonsleveranser, bør gå gjennom sine antakelser om hva som skjer når plattformen svikter.

Praktiske tiltak kan være å ha sikkerhetskopier eller speil av repositories, sørge for at CI/CD-oppsett kan flyttes, dokumentere rutiner for nødutgivelser og sikre at team vet hvordan de skal arbeide når SSO, Webhooks eller vertsbaserte runners er utilgjengelige.

Slike tiltak fjerner ikke plattformrisikoen, men kan begrense skadeomfanget ved neste forstyrrelse. Den endelige vurderingen av 17. august avhenger av GitHubs postmortem. Inntil den foreligger, er den mest forsvarlige konklusjonen begrenset: GitHub opplevde en bred og kaskaderende tjenesteforstyrrelse med alvorlige konsekvenser for repository-nedlastinger og sammenkoblede utviklerarbeidsflyter. Tjenestene kom tilbake trinnvis, men den underliggende feilen er ennå ikke offentlig forklart.