GitHub in tilt il 17 agosto: cosa è successo e cosa sappiamo

In un aggiornamento pubblicato alle 12:36 EDT — le 18:36 in Italia — GitHub ha comunicato di aver identificato il componente coinvolto e di aver preso provvedimenti correttivi. La piattaforma mostrava «forti segnali di ripresa», ma non era ancora completamente stabile.

Il recupero non è stato simultaneo. I principali servizi sono tornati operativi mentre Copilot continuava a presentare problemi di autenticazione in alcune applicazioni. Secondo altri resoconti, l’incidente complessivo si è concluso intorno alle 21:15 UTC, ovvero alle 23:15 in Italia, dopo quasi otto ore dall’inizio delle anomalie.

Quanto è stato grave il disservizio?

I dati più chiari arrivano dai tassi di errore comunicati da GitHub:

• Sito e traffico API: circa 20% di errori.
• Download degli archivi e dei contenuti raw dei repository: circa 50% di errori.
• Strumenti per sviluppatori: Pull Request, Issues, Actions, Webhooks, operazioni Git e Pages hanno registrato rallentamenti o indisponibilità in momenti diversi.
• Assistenza alla programmazione basata sull’AI: GitHub Copilot è stato coinvolto e ha continuato a presentare problemi anche dopo il recupero di diversi servizi principali.
• Identità aziendale: sono state segnalate difficoltà con autenticazione SAML e OIDC, provisioning SCIM e Team Sync, funzioni che le organizzazioni usano per autenticare gli utenti e amministrare gli accessi.

Queste percentuali descrivono le richieste fallite, non la quota esatta di utenti rimasti completamente senza servizio. Un tasso di errore API del 20% non significa che il 20% dei clienti sia stato necessariamente offline; allo stesso modo, il 50% riguarda le richieste di download interessate e non tutto il traffico dei repository.

Perché il lunedì mattina ha amplificato l’impatto

L’incidente è iniziato il lunedì mattina negli Stati Uniti, in corrispondenza dell’avvio della settimana lavorativa per molte squadre di sviluppo. È una fascia oraria delicata: spesso coincide con i primi cicli di code review, test automatici, integrazione continua, distribuzioni e pianificazione del lavoro.

In questo caso non era coinvolta una sola funzione. Actions, Pull Request, API e Webhooks facevano parte dello stesso quadro di degrado, così un team poteva incontrare errori in più passaggi collegati del flusso di sviluppo, anziché in uno strumento isolato.

Anche il numero delle segnalazioni pubbliche è variato a seconda dell’orario e del sistema di monitoraggio. Un resoconto ha riferito di oltre 10.000 segnalazioni su Downdetector entro le 8:12 del mattino sulla costa pacifica degli Stati Uniti, mentre un aggiornamento sulla ripresa ha indicato un picco di quasi 3.000 segnalazioni. Non sono numeri equivalenti a un conteggio preciso degli utenti colpiti: i tracker raccolgono segnalazioni volontarie e i risultati cambiano in base a area geografica, momento della rilevazione e metodologia.

Che cosa ha fatto GitHub

Gli aggiornamenti pubblici permettono di ricostruire tre elementi della risposta:

1. Gli ingegneri hanno indagato su problemi di prestazioni elevati che coinvolgevano più servizi.
2. GitHub ha individuato un componente problematico e ha applicato misure correttive.
3. Dopo il recupero dei principali servizi, l’azienda ha continuato a introdurre mitigazioni, anche per gli errori sporadici di autenticazione di Copilot.

Non è invece possibile affermare, sulla base delle informazioni disponibili, quale fosse il componente coinvolto, quale correzione tecnica sia stata applicata o che la pressione sulla capacità abbia causato proprio questo incidente. La crescita del traffico legata agli strumenti di sviluppo basati sull’AI e i limiti dell’infrastruttura fanno parte della più ampia discussione di GitHub sull’affidabilità, ma non costituiscono una causa confermata del disservizio del 17 agosto in assenza del postmortem.

Un altro capitolo dei problemi di affidabilità del 2026

L’outage è arrivato dopo un periodo difficile per la piattaforma. Nel suo rapporto sulla disponibilità di luglio, GitHub ha documentato otto incidenti. Uno di questi, l’8 luglio, è durato più di sette ore e ha coinvolto Web UI, API REST, API GraphQL, Actions, Packages, Copilot e operazioni Git in alcuni ambienti Enterprise Cloud.

GitHub ha inoltre descritto una sfida infrastrutturale più ampia: il traffico sta crescendo rapidamente, in parte per effetto dei flussi di sviluppo assistiti dall’AI e dei sistemi “agentici”, cioè capaci di eseguire autonomamente una serie di attività. Tra le risposte indicate dall’azienda figurano lo spostamento di maggiore capacità verso Azure, la separazione dei servizi e la riduzione dei punti di guasto condivisi.

La portata del piano è significativa. Secondo i resoconti sui progetti infrastrutturali, l’obiettivo iniziale di aumentare la capacità di 10 volte è stato sostituito dalla necessità di progettare una piattaforma capace di sostenere fino a 30 volte la scala di allora. Altri articoli hanno descritto interventi che coinvolgono Azure e ulteriore capacità multicloud, inclusa AWS; questi piani, però, non spiegano automaticamente la causa dell’incidente di agosto.

Il punto centrale è la dipendenza da una singola piattaforma. GitHub oggi non è soltanto il luogo in cui vengono conservati i repository Git: è anche uno spazio di collaborazione, una piattaforma per l’automazione, un sistema di gestione delle identità e un servizio di programmazione assistita dall’AI. Quando una dipendenza condivisa si guasta, lo stesso incidente può interrompere accesso al codice, revisioni, build, rilasci, Webhooks e assistenza alla programmazione.

Che cosa dovrebbero verificare le organizzazioni

L’incidente non dimostra che gli sviluppatori stiano per abbandonare GitHub e non ci sono elementi sufficienti per prevedere un’imminente migrazione di massa. Mostra però perché le aziende che dipendono da GitHub per distribuire software dovrebbero rivedere i propri piani di continuità operativa.

Tra le misure pratiche rientrano:

• mantenere backup o mirror dei repository;
• usare configurazioni CI/CD il più possibile portabili;
• documentare procedure di rilascio d’emergenza;
• preparare modalità operative alternative in caso di indisponibilità di SSO, Webhooks o runner ospitati;
• verificare in anticipo come continuare a lavorare quando autenticazione e automazione non sono disponibili.

Queste precauzioni non eliminano il rischio legato al fornitore, ma possono ridurre l’impatto del prossimo disservizio.

Il giudizio definitivo sull’incidente del 17 agosto dipenderà dal postmortem di GitHub. Fino ad allora, la conclusione più solida è circoscritta: GitHub ha subito un’interruzione ampia e a effetto cascata, con conseguenze particolarmente gravi sui download dei repository e sui flussi di lavoro collegati degli sviluppatori; il ripristino è avvenuto per fasi e la causa tecnica di fondo non è ancora stata resa pubblica.