GitHub heeft te maken met storingen

GitHub heeft te maken met storingen, zo laat het bedrijf weten. Veel onderdelen leveren 'mindere prestaties', meldt het bedrijf. De oorzaak is onbekend en ook is onduidelijk hoe lang het gaat duren.

Het Microsoft-dochterbedrijf onderzoekt de storingen, zo staat op de Status-website. De storingen begonnen rond drie uur 's middags Nederlandse tijd en duren op het moment van schrijven meer dan twee uur. Volgens de Status-website heeft lang niet iedereen er last van, maar treffen de storingen wel veel onderdelen. Daarbij gaat het om bezoekers van de site, pullrequests, api-requests, Copilot en meer.

GitHub-storing augustus 2026

Reacties (46)

[HollowGamer]

Het grappige is dat ze volgens hun status 99.99 % uptime (of alles eromheen), nog steeds halen.

Ik neem deze cijfers niet meer serieus, want elke dag zijn er issues, gok dat het eerder rond de 80-90% ligt de afgelopen tijd.

[SmokingCrop]

Deze toont alles en samengevoegd, zal al een stuk meer "kloppen": The Missing GitHub Status Page

[Reactie gewijzigd door SmokingCrop op 17 augustus 2026 17:39]

[keranoz]

Het opsplitsen per service is toch duidelijker ook? Ja het laat een lager uptime percentage zien, maar het is toch niet eerlijk om zeggen "heel GH ligt plat" als 1 onderdeel eruit ligt? Je zou dan ook kunnen zeggen "Microsoft ligt plat" en dan het Microsoft uptime percantage verlagen omdat er bij GH een storing is, een Windows update faalt of Flight Simulator niet start.

edit:
Wilde nog even toevoegen dat ik het wel met jullie eens ben qua geveoel. Ik gebruik Github ook dagelijks, en die unicorns zijn niet meer zo rare als ze een paar jaar geleden waren.

[Reactie gewijzigd door keranoz op 17 augustus 2026 18:16]

[SmokingCrop]

Klopt, maar als je de helft van die functies gebruikt, dan is het gemiddelde nemen van de uptime percentages per service ook niet correct.

Je zou het dan eigenlijk al selecteerbaar moeten maken waarbij het dan jouw persoonlijke uptime percentage geeft voor de diensten van Github die je gebruikt.

De individuele uptime percentages liggen bij de status pagina van Github ook lager, daar doen ze ook nog wat om de cijfers er beter uit te laten zien. Als iets 20% down is, reken je het dan als een outage of maar als een 20% outage in zo'n uptime calculator...

Het uptime percentage is dan ook niet meer simpelweg "is Github down".

[Reactie gewijzigd door SmokingCrop op 17 augustus 2026 18:57]

[Mars Warrior]

Update - We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. SAML and OIDC authentication, SCIM, and Team Sync are also impacted. We are currently performing mitigations and will post updates as we progress.

Ik kan ook niet afleiden wat de uptime zegt over een 50% error rate: is het dan up of down?

En sommige diensten zijn gekoppeld: de ene dienst kan niet zonder de andere vanuit het oogpunt van de gebruiker. Dus alles met een error rate van 20% kan vanuit de gebruiker heel simpel "DOWN" betekenen.

[Ricco02]

99.99% over welk tijdsbestek?

Als dit over het hele afgelopen jaar is dan kan 99.99% wel.

[Raymond Deen]

Elk uur down per jaar is 0,1% ongeveer. Dus 0,01% is vrijwel onhaalbaar, want dat is dan maar 6 minuten op het hele jaar.

Vooral platform en Actions lagen er behoorlijk wat uurtjes uit afgelopen jaar, zo’n 10 tot 15 uur allebei, dus dan kom je eerder tot een 99,8x%

Zelfhostend zal je het wellicht minder makkelijk zo hoog krijgen als wanneer zij het doen voor je, maar het laat wel weer de afhankelijkheid goed zien.

[IStealYourGun]

0,01 is 52 min op jaarbasis, maar vaak wordt er met maanden gewerkt en dat is 4 minuten

0,1% is +8h op jaarbasis en 43 min op maandbasis.

[Raymond Deen]

I stand corrected. Maar een factor 10 vergist. 🤣

[Nimac91]

Ik heb werkelijk nog nooit een issue met github meegemaakt. En ik heb 13 websites die via github deployen op mijn VPS.

Mijn commits, fetches en pushes hebben ook altijd gewerkt. Denk dat jij gewoon een keer op verkeerde moment verkeerde plek een keer een issue hebt meegemaakt maar kan echt niet geloven dat het rond de 80-90% ligt. snap je dat 10 tot 20% downtime betekent dat je meer dan 2 maanden in zijn geheel offline bent? Om uberhaubt meer dan 1% downtime te krijgen is zeer bijzonder tenzij je dagelijks DDOS attacks krijgt is dat niet een ding. Github werkt prima, Azure systemen vallen niet zo vaak weg uit mijn ervaring.

[HollowGamer]

Wat fijn dat jij nooit vervelende dingen meemaakt. Mag ik met jouw ruilen?

[SJCE]

Toen ik vorige maand naar de issues in claude-code keek, moest ik 10-20 keer proberen voordat m'n gh expressie de paar honderd MB aan json resultaten opleverde. Dat was dus meer dan een volledige dag met alleen maar time-outs. https://www.linkedin.com/posts/stephan-eggermont-825a001_gtoolkit-moldabledevelopment-activity-7475976028893552640-T1Y8

[Cino]

Mijn commits, fetches en pushes hebben ook altijd gewerkt. Denk dat jij gewoon een keer op verkeerde moment verkeerde plek een keer een issue hebt meegemaakt maar kan echt niet geloven dat het rond de 80-90% ligt

Misschien dat 80% overdreven is maar meerdere uren per week lijkt er wel op, als ik de history in onze Slack (notifications channel hiervoor) terug kijk, en de klachten van engineers binnen ons bedrijf is het echt niet mals. Ik ben er inmiddels zeer van overtuigd dat grotere bedrijven gewoon over moeten stappen op self-hosted Gitlab / Forgejo omdat het zo onbetrouwbaar is geworden. Van unicorns tot niet werkende github actions / webhooks die niet afgevuurd worden.

[Krommetenen]

Laten we het zo zeggen, dat er ergens wel iets van Github online stond ondanks de andere storingen.

[perry]

Wel interessant als extra context bij de storingen: GitHub heeft de afgelopen maanden echt een enorme groei in gebruik gezien, voor een groot deel gedreven door AI.

In oktober 2025 werkte GitHub nog aan een plan om de capaciteit met 10x op te schalen. Een paar maanden later bleek dat alweer te weinig en werd er inmiddels ontworpen voor ongeveer 30x de toenmalige schaal.

Dat zie je ook terug in de cijfers. Volgens GitHub-COO Kyle Daigle ging GitHub van ongeveer 1 miljard commits in heel 2025 naar zo'n 275 miljoen commits per week in april 2026. GitHub Actions groeide ondertussen van ongeveer 1 miljard naar 2,1 miljard minuten gebruik per week.

Ook repository creation, pull requests, API-gebruik en automatisering zijn volgens GitHub flink toegenomen. In vier maanden tijd hebben ze de effectieve capaciteit van het platform al meer dan verdubbeld.

Bronnen:
https://github.blog/news-insights/company-news/an-update-on-github-availability/
https://github.blog/news-insights/company-news/github-availability-report-may-2026/ https://simonwillison.net/2026/Apr/4/kyle-daigle/

[Reactie gewijzigd door perry op 17 augustus 2026 19:25]

[Powerblast]

Op zich niet onlogisch inderdaad, nu iedere knul op de hoek begint te vibe coden en dus blijkbaar op z'n minst toch doorheeft dat code bewaren op een C schijf niet het slimste is.

Vraag me alleen af of die groei zich op lange termijn ook doorzet, eens het nieuws er wat af is. Aantal commits verwacht ik wel dat dit stabiel blijft, met AI worden er denk ik meer kleine commits gemaakt om het overzichtelijk te houden. Nieuwe repo's verwacht ik persoonlijk dat dit inzakt. Na 10 vibe coded TODO apps hebben we het toch wel weer gehad denk ik dan . Of het wordt de nieuwe hello world, dat kan ook natuurlijk.

Vind het wel vrij zuur voor Github. want had verwacht met een moederbedrijf zoals Microsoft dat Azure capaciteit toch zo ter beschikking moet kunnen stellen, dat ze blijkbaar dan toch nog tegen dezelfde soort issues aanlopen.

[perry]

Oh nee, helemaal eens! Ik denk alleen dat je dit niet puur oplost door meer compute vanuit Azure beschikbaar te maken.

Op een gegeven moment zit de bottleneck niet meer bij CPU of geheugen, maar bij dingen als databases, queues, caches, storage en interne services die ineens veel meer werk moeten verwerken. Zeker bij een platform als GitHub, waar een push achter de schermen meteen van alles in gang zet: indexing, webhooks, Actions, status checks, API-events en notificaties. Als iets niet lekker meeschakelt, kun je er nog zoveel extra machines naast zetten, maar dan verplaats je het probleem vooral.

Dus ik denk dat de uitdaging vooral zit in het hele platform op die nieuwe schaal betrouwbaar laten draaien, niet alleen in capaciteit erbij gooien.

[kakanox]

Eigenlijk zou je denken dat met AI de code bewaren steeds minder belangrijk wordt. Misschien hebben we over een paar jaar alleen nog maar de prompts in GitHub staan?

Bij mij werkt het overigens wel weer, maar het is nog steeds erg traag.

[Ypho]

De storing begon voor mij pas rond 1700. Ik heb tot kwart voor 5 de hele dag zonder issues kunnen git’en, vooral geluk gehad dus.

[Reactie gewijzigd door Ypho op 17 augustus 2026 17:28]

[__fred__]

Investigating - We are investigating reports of impacted performance for some GitHub services.
Aug 17, 2026 - 13:40 UTC

Ik heb al wel gedoe gehad rond 15:30, dus denk dat ze zelf wel aardig weten.

[C-asper]

De eerste post op de status pagina is van 13:40 UTC

[Damic]

Ja dat is 15:40 onze tijd (utc+1+DST)

[Groax]

Dit ja, 15:45 brak de pull die ik wilde doen.

[RobertMe]

En ik merkte voor 4 uur al issues met /issues (/issues tab). In de zin van: helemaal niet te openen en elke keer een "unicorn". Het ligt er dus maar net aan wat je aan het doen was.

[Frenziefrenz]

Ik kreeg eerst nog een leukere: dat het issue niet zou bestaan. Gelukkig nu een eenhoorn.

[Nedje]

Dan ben je een uitzondering. Vanaf een uur of drie storte veel van onze pipelines (GHES + GHEC) in elkaar omdat onze Actions mirror blijkbaar toch niet helemaal compleet was.

Dat uitte zich vooral in een 429 bij het downloaden van specifieke actions.

[bazzi]

Ook hier, geeft wel direct aan dat het een zwakte is in ons process waar we wat mee moeten 😉

[Nedje]

Absoluut! Helaas worden dit soort mirrors bij ons op bedrijfsniveau geregeld. Zaken daar aan toevoegen moet door wat bureaucratie en dat is het niet altijd waard. Voor sommige pipelines moeten we dat zeker doen.

Never waste a good crisis (al was deze voor ons maar klein)

[Martijn.C.V]

En waar ik net achter kwam: Het installeren van een package (bijv. met Composer) dat op Github staat werkt ook niet (stabiel).

Ik kan best een beetje vooruit werken zonder Git, maar geen PR, geen reviewen, geen installs (bijv. bij een branchwissel); dan wordt het vlot moeilijk om m'n werk te doen.

[dasiro]

staat al 3x in hun updates:

raw repository content downloads are experiencing an approximate 50% error rate.

[Groax]

Haha same problem here, dus ben maar naar huis gegaan. Werkte dikke prima tot ik van branch wisselde en composer update deed.

[JJ Le Funk]

Dacht vanmiddag aanvankelijk dat ik door mijn tokens heen was.

[MrFax]

Hopelijk krijgen we straks geen tokens om toegang te krijgen tot websites... Geef ze nou geen ideeën.

[Keypunchie]

Access tokens bestaan al heel lang. :-p

Wikipedia: Access token

[SadisticPanda]

Unicorn

[SuperSonicFreak]

Ik zag tussen 1611-16:13 op een pagina, nu nog steeds:

Cannot retrieve latest commit at this time.

Al heb ik geen ervaring wat het exact inhoud, maar begrijp (na googlen) dat het achterlopende repos te maken heeft en/of soortgelijke storingen zoals deze.

[joyrider3774]

ik heb al langer problemen met github zaken of zelfs de site die niet deftig wil laden. Soms werkt alles normaal maar heel af en toe blijft de site oneindig laden, het grappig is als ik een 2de tabblad open doe in chrome en de github site voor een tweede maal laad, laben beiden tabbladen onmiddelijk de site. Dit is al maanden aan de gang en soms werkt het gewoon normaal en soms moet ik die omzeiling met dat 2de tabblad uitvoeren. Het ligt niet aan dns en ook niet aan (tijdelijke) niet bereikbaarheid van de site of zo. Heb al vanalles zitte zoeken, maar blijkbaar ben ik niet de enige met dit probleem

[berchtold]

Dit is toch geen nieuws. Dit is meerdere keren per week

[kil98q]

Zat midden in een storing en vervolgens begeeft git het ook nog is voor 20 minuten. Wel mooie unicorn