Il 13 settembre 2026 GitHub ha avuto un incidente che ha colpito circa 28 servizi, ma il punto più interessante non è il numero di componenti coinvolti: è il modo in cui un normale job interno di pulizia dati è riuscito a saturare un database condiviso e a propagare errori in tutta la piattaforma. Il postmortem ufficiale descrive un caso classico di effetto cascata: un carico di background apparentemente controllato, un segnale di salute osservato nel posto sbagliato e un meccanismo di retry che ha continuato ad aggiungere pressione proprio mentre il sistema stava già degradando.
È una storia utile anche fuori da GitHub perché mostra quanto possano diventare fragili i sistemi distribuiti quando più servizi dipendono dallo stesso componente critico. Non servono per forza un attacco o un guasto hardware: a volte basta un’operazione interna legittima che incontra una protezione incompleta.
Cosa è successo a GitHub il 13 settembre
Secondo il resoconto pubblicato da GitHub Status, l’incidente ha degradato servizi come Issues, Pull Requests, Actions, Codespaces, Pages, Notifications, Code Scanning, Git LFS e la registrazione di nuovi account. La finestra principale è andata dalle 08:43 alle 10:44 UTC.
Il problema è partito da un job interno di pulizia dati avviato su un cluster database condiviso che contiene informazioni di autorizzazione lette da quasi ogni richiesta autenticata. Quel job ha iniziato a scrivere sul database alle 07:33 UTC e, con il passare del tempo, ha portato il server primario sempre più vicino al limite.
Il sistema aveva una protezione pensata per rallentare il job in caso di problemi, ma monitorava soprattutto il ritardo delle repliche. Quel valore è rimasto basso, quindi il job ha continuato a lavorare anche mentre il nodo primario stava accumulando pressione.
Il dettaglio che rende interessante il postmortem
Il punto chiave è che il controllo non era assente: stava semplicemente guardando il segnale sbagliato. La replica sembrava sana, ma il database primario non lo era più. Questo è uno dei rischi più comuni nei sistemi complessi: una metrica locale può restare verde mentre una dipendenza centrale sta andando verso la saturazione.
Per GitHub il problema era particolarmente serio perché quel cluster non gestiva un servizio marginale. Conteneva dati di permesso e autorizzazione richiesti in moltissime operazioni. Quando quel database ha iniziato a rallentare, i sintomi sono comparsi in aree molto diverse della piattaforma.
Il risultato è stato un incidente che sembrava composto da molti problemi separati, ma aveva una dipendenza condivisa al centro.
Il retry loop ha peggiorato la saturazione
Quando le richieste per la creazione di alcuni token hanno iniziato a fallire, una parte del sistema ha continuato a ritentare. Il postmortem descrive un comportamento che ha aumentato ulteriormente il numero di scritture verso un database già sotto pressione.
Questo è il lato controintuitivo dei retry automatici: servono per rendere un servizio più resiliente, ma senza limiti possono amplificare un guasto. Se cento richieste falliscono e ognuna riprova immediatamente più volte, il componente in difficoltà riceve ancora più traffico proprio nel momento peggiore.
La stessa logica vale in molte architetture moderne: API, code, database e microservizi hanno bisogno di retry con backoff, limiti e criteri di abbandono. Ritentare all’infinito non equivale a essere più affidabili.
Quanto è stato grande l’impatto
GitHub ha riportato numeri molto concreti. Al picco, una parte delle richieste per creare token di installazione GitHub App falliva, diversi workflow Actions non riuscivano a ottenere i token necessari e la creazione di Issues dal web risultava quasi completamente compromessa.
Il dato più interessante non è però la singola percentuale. È il fatto che un problema nato in un job di manutenzione sia riuscito a raggiungere funzionalità molto lontane tra loro. Questo mostra quanto può pesare una dipendenza condivisa quando si trova sul percorso critico dell’autorizzazione.
Come GitHub ha recuperato il servizio
Durante l’incidente GitHub ha ridotto il carico sul cluster e applicato meccanismi di load shedding per permettere al database di recuperare. Ma la parte più utile del postmortem arriva dopo: l’azienda ha elencato una serie di modifiche strutturali per evitare che lo stesso schema si ripeta.
- Rate limiting sui job di background che lavorano contro database condivisi usati anche dal traffico degli utenti.
- Pause automatiche quando il server primario mostra segnali di carico e non soltanto quando aumentano i ritardi di replica.
- Retry limitati nei percorsi di emissione dei token.
- Timeout per richiesta per evitare che un database malato occupi indefinitamente la capacità dei web server.
- Più visibilità operativa sui job di background direttamente nelle dashboard di salute del database.
- Separazione del cluster per ridurre il numero di servizi dipendenti dalla stessa base dati.
Perché dividere il database è una correzione più importante del singolo fix
Limitare i retry e migliorare il monitoraggio riduce il rischio di una nuova saturazione, ma GitHub ha indicato anche una misura architetturale più profonda: spostare dati di servizi differenti fuori dal cluster condiviso.
È una scelta costosa perché richiede migrazioni, compatibilità e nuovi confini operativi, ma riduce il cosiddetto blast radius. Se un database dedicato a una parte della piattaforma ha problemi, il guasto ha meno possibilità di trascinare con sé tutto il resto.
In altre parole, il postmortem non si limita a correggere il job che ha innescato l’incidente. Cerca di rimuovere le condizioni che hanno permesso a quel job di avere un impatto così grande.
La lezione sui sistemi di monitoraggio
Una delle lezioni più utili è che monitorare una replica sana non significa monitorare un database sano. Un sistema complesso va osservato attraverso segnali che rappresentano direttamente la risorsa che può diventare il collo di bottiglia.
CPU, connessioni, code, latenza, write pressure, errori applicativi e saturazione possono raccontare storie differenti. Se una protezione automatica dipende da una sola metrica, il rischio è che quella metrica non veda il guasto reale.
Per questo i meccanismi automatici di protezione dovrebbero essere costruiti attorno a più segnali e, soprattutto, alla capacità reale del componente critico che stanno cercando di proteggere.
Perché questo caso conta anche per chi usa GitHub ogni giorno
Per gli utenti, l’incidente è durato poco più di due ore. Per chi progetta sistemi, però, è un esempio molto più duraturo: mostra come un’attività di manutenzione interna possa trasformarsi in un problema di disponibilità globale quando passa attraverso una dipendenza centrale.
Il tema si collega anche alla sicurezza dei flussi di sviluppo. Nel nostro approfondimento su agenti AI e repository GitHub abbiamo visto quanto il contesto del repository possa influenzare strumenti automatici. Nel lavoro quotidiano sugli agenti di coding è utile anche capire come orchestrare più strumenti, come nella guida su Codex dentro Claude Code.
Il punto più importante del postmortem GitHub
GitHub non è andato in crisi perché mancavano controlli, ma perché i controlli disponibili non descrivevano abbastanza bene lo stato reale del sistema. Il job di background continuava a lavorare, la replica sembrava in ordine e i retry provavano a recuperare. Presi singolarmente, erano tutti comportamenti plausibili. Insieme hanno aumentato il danno.
È questo che rende il caso interessante come storia tecnica: l’incidente non nasce da una singola riga di codice palesemente sbagliata, ma dall’interazione tra automazione, monitoraggio, dipendenze condivise e strategie di recupero.
Il resoconto ufficiale dell’incidente è disponibile su GitHub Status.
Entra nella conversazione
Condividi il tuo punto di vista: non serve creare un account. I contributi restano soggetti alla moderazione editoriale.