GitHub sta ampliando rapidamente la propria infrastruttura dopo una nuova serie di problemi di disponibilità legati alla crescita del traffico sulla piattaforma. Il 17 agosto 2026 il servizio ha registrato un’interruzione durata 7 ore e 47 minuti che ha coinvolto github.com, autenticazione, GitHub Actions, API, pull request, issue e Copilot. L’incidente è stato il secondo evento significativo del mese dopo il problema che aveva interessato GitHub Actions il 6 agosto e, secondo l’analisi tecnica effettuata successivamente, non è stato causato da una modifica al codice o alla configurazione. Alla base si è verificato invece un problema di capacità: il traffico ha raggiunto un nuovo picco e un componente infrastrutturale critico nel data center Central US non è riuscito a scalare abbastanza rapidamente, propagando la pressione agli altri sistemi e provocando errori di autenticazione e indisponibilità di diversi servizi.
Il recupero ha richiesto il reindirizzamento del traffico, l’isolamento dell’infrastruttura interessata e il ripristino progressivo dei servizi. Gran parte della piattaforma è tornata operativa prima della completa risoluzione dell’incidente, mentre alcuni componenti di Copilot hanno richiesto più tempo. Gli errori registrati dai servizi Copilot hanno inoltre innescato un ciclo di retry lato client che ha prodotto ulteriore traffico durante la fase di recupero, aumentando il carico proprio mentre l’infrastruttura stava tornando alla normalità. GitHub ha dovuto quindi mitigare anche questo comportamento prima di poter ripristinare completamente il traffico. L’azienda ha ricondotto sia l’incidente del 6 agosto sia quello del 17 agosto a problemi di capacità, riconoscendo che alcuni componenti critici non erano stati dimensionati abbastanza rapidamente rispetto all’aumento della domanda.
La crescita registrata negli ultimi mesi mostra l’entità del cambiamento. Ad aprile GitHub elaborava circa 1,4 miliardi di commit al mese, mentre ad agosto il volume ha raggiunto 2,9 miliardi, più che raddoppiando nell’arco di quattro mesi. Nello stesso periodo sono aumentati anche altri indicatori della piattaforma: i grafici diffusi da GitHub mostrano i pull request uniti mensilmente salire verso quota 130 milioni e la creazione di nuovi repository raggiungere circa 24 milioni al mese. Anche i job completati attraverso GitHub Actions sono cresciuti fortemente durante il 2026, passando da livelli nell’ordine di 15-30 milioni nelle prime fasi dell’anno a picchi superiori ai 100 milioni, con gli ultimi valori mostrati intorno a 115,4 milioni.
Per sostenere questo aumento dei carichi, GitHub ha concentrato gli interventi su espansione della capacità, miglioramento dell’efficienza e rimozione dei colli di bottiglia architetturali. La piattaforma ha aggiunto oltre 3 milioni di core CPU, 120 petabyte di storage ad alta velocità e una quantità significativa di nuova capacità di rete. Nei data center esistenti è stato installato hardware fino ai limiti consentiti dalla potenza elettrica disponibile, mentre contemporaneamente è stata accelerata la migrazione verso Microsoft Azure, utilizzata come fonte di capacità maggiormente elastica rispetto all’espansione dei soli impianti proprietari.
Il peso di Azure nell’infrastruttura di GitHub è aumentato molto rapidamente. A maggio 2026 il cloud Microsoft gestiva circa il 12% del carico complessivo della piattaforma, mentre ad agosto la quota era già salita a circa il 58%. Azure gestisce inoltre circa la metà di tutte le operazioni Git. Questa espansione ha fornito capacità aggiuntiva anche per GitHub Actions e sta contribuendo al lavoro necessario per gestire i monorepository di dimensioni maggiori. Il prossimo obiettivo infrastrutturale riguarda un’architettura capace di aumentare linearmente la capacità di lettura al crescere del numero di reader, con l’obiettivo di eliminare di fatto i limiti alle operazioni di lettura; l’implementazione sarà progressiva e partirà proprio dai monorepository più grandi.
Il problema non riguarda però esclusivamente la quantità di risorse disponibili. GitHub ha riconosciuto che l’aumento simultaneo della scala e della complessità operativa è stato più rapido dell’evoluzione di alcune procedure interne. Per questo parte dei team e delle risorse è stata riallocata verso l’affidabilità della piattaforma, con investimenti in test più robusti, procedure di rollout più sicure, maggiore osservabilità dell’infrastruttura e sistemi di alerting più efficaci. Parallelamente è in corso l’isolamento dei sistemi critici e la rimozione delle dipendenze condivise tra differenti componenti, in modo che il guasto o la saturazione di un singolo servizio abbiano meno probabilità di propagarsi all’intera piattaforma.
Gli incidenti di agosto hanno già prodotto due modifiche operative immediate. GitHub sta introducendo limiti di retry uniformi, veri e propri retry budget e timeout variabili nelle comunicazioni tra servizi, così da evitare che un componente in errore generi automaticamente grandi quantità di nuove richieste e provochi retry storm capaci di amplificare un sovraccarico iniziale. È stata inoltre avviata una revisione degli alert relativi a CPU e memoria precedentemente classificati come meno prioritari, con l’obiettivo di individuare prima i componenti che potrebbero raggiungere il limite durante improvvisi picchi di traffico.
La pressione infrastrutturale si inserisce in una trasformazione iniziata già alla fine del 2025. GitHub aveva avviato nell’ottobre 2025 un piano per aumentare di dieci volte la capacità della piattaforma, ma entro febbraio 2026 aveva già stabilito che l’architettura avrebbe dovuto essere progettata per sostenere una scala futura pari a circa trenta volte quella precedente. Tra i fattori indicati rientra l’espansione dei workflow di sviluppo agentico, che dalla seconda metà di dicembre 2025 ha accelerato contemporaneamente creazione di repository, attività sulle pull request, utilizzo delle API, automazione e carichi associati ai repository più grandi.
L’aumento da 1,4 a 2,9 miliardi di commit mensili rappresenta quindi uno degli indicatori utilizzati direttamente da GitHub per spiegare il salto di carico osservato negli ultimi mesi, mentre l’aggiunta di milioni di core CPU e la rapida migrazione verso Azure costituiscono la risposta infrastrutturale già in corso. L’obiettivo tecnico è combinare maggiore capacità fisica e cloud con una progressiva separazione dei componenti, sistemi di lettura più scalabili e meccanismi di protezione contro carichi ricorsivi e failure a cascata, dopo che gli incidenti di agosto hanno mostrato che l’espansione della domanda ha superato la capacità di alcuni elementi critici dell’architettura esistente.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)