GitHub è rimasto offline per quasi 8 ore il 17 agosto
GitHub.com ha subito un blackout di 7 ore e 47 minuti il 17 agosto 2026, dalle 13:28 alle 21:15 UTC, che ha degradato quasi ogni workflow centrale per gli sviluppatori sulla piattaforma. Errori e latenze elevati hanno colpito contemporaneamente Issue, Pull Request, le API REST e GraphQL, GitHub Actions e GitHub Copilot, quindi l'interruzione non si è limitata a una singola funzione. Il post-mortem di GitHub, pubblicato su github.blog con il titolo "The August 17 outage and the work ahead", indica un tasso di errore massimo intorno al 20% su tutto il sito, e intorno al 50% specificamente per i download di archivi e file raw. The Register, TechTimes e dev.to hanno confermato tempistica e portata nella propria copertura dell'incidente.
| Metrica | Valore |
|---|---|
| Inizio (UTC) | 13:28 |
| Fine (UTC) | 21:15 |
| Durata | 7 ore 47 minuti |
| Tasso di errore massimo, sito intero | ~20% |
| Tasso di errore massimo, download archivio/raw | ~50% |
La causa è stata un proxy al limite, non un deploy difettoso
Il post-mortem di GitHub afferma chiaramente che il blackout non è stato causato da un deploy di codice o configurazione; è stato un guasto di capacità e monitoraggio all'interno dell'infrastruttura di rete dell'azienda stessa. Il fattore scatenante è stato un proxy sidecar di service mesh di Istio in un data center di Central US che ha raggiunto il proprio limite di concorrenza quando il traffico è arrivato con un nuovo picco per cui il sistema non era dimensionato. Un sidecar di service mesh si trova accanto a ogni istanza di servizio per gestirne il traffico di rete, quindi quando uno raggiunge un limite rigido sotto un carico inatteso, tutto ciò che vi transita fallisce in blocco invece di degradarsi gradualmente.
Un avviso mal configurato ha fatto sì che nessuno se ne accorgesse in tempo
Una policy interna di monitoraggio era mal configurata e non ha avvisato gli ingegneri di GitHub quando il proxy sidecar si avvicinava al proprio limite di concorrenza, quindi l'allerta che avrebbe dovuto attivare una risposta prima che gli utenti notassero qualcosa semplicemente non è scattata. Quel vuoto conta quanto il limite di concorrenza in sé: un limite di capacità individuato per tempo è un aggiornamento silenzioso, uno individuato solo dopo che gli utenti vedono errori diventa un incidente di più ore. GitHub afferma che colmare quel vuoto di monitoraggio fa parte del "work ahead" citato nel titolo del post-mortem.
I retry di GitHub, soprattutto da VS Code, hanno peggiorato tutto
La logica ottimistica di retry lato client in tutto l'ecosistema GitHub ha trasformato un proxy sovraccarico in una cascata sull'intera piattaforma, e GitHub ha indicato una tempesta di retry dai client di VS Code come fattore determinante nella gravità del blackout. Quando una richiesta fallisce e un client la ritenta subito senza attesa, non fallisce soltanto di nuovo, ma aggiunge un'altra richiesta a un sistema già sovraccarico, e moltiplicato per milioni di installazioni di VS Code che interrogano GitHub in background, questo schema ha trasformato un problema di proxy contenuto in un problema dell'intera piattaforma. È questo il dettaglio che trasforma l'incidente da una storia sull'infrastruttura di GitHub a una storia su come dovrebbe essere costruito qualunque client di qualunque API.
Per ogni azienda con la pipeline su GitHub, sono state 8 ore di blackout
La maggior parte delle aziende considera un blackout di GitHub un fastidio per gli sviluppatori, qualcosa di cui lamentarsi mentre si aspetta, ma per ogni azienda che ha inserito silenziosamente GitHub Actions e Copilot nella propria pipeline di rilascio, 7 ore e 47 minuti senza GitHub sono 7 ore e 47 minuti in cui non si può rilasciare un hotfix, non si può unire una patch di sicurezza e, se Copilot fa parte del workflow, si perde uno strumento di coding assistito dall'IA a metà di un'attività. È un rischio di concentrazione su un unico fornitore nascosto dentro quello che sembra "usare semplicemente GitHub", e non compare in nessuna voce di budget come farebbe un abbonamento software. La lezione più tagliente è la tempesta di retry: se il software client di GitHub ha peggiorato un blackout ritentando in modo aggressivo senza attesa, ogni azienda che costruisce i propri sistemi contro API di terze parti dovrebbe verificare la propria logica di retry per lo stesso difetto, invece di archiviarlo come un problema esclusivo di GitHub.
Da leggere ora: L'Agente IA di Wiz Ha Violato Snowflake e Incolpato Copilot | Il Vostro Secondo Host Git Si È Attivato Da Solo
