Il servizio che autorizza Copilot è rientrato quattro ore dopo il resto di GitHub

Cosa si è rotto

Il 17 agosto 2026, dalle 13:28 alle 21:15 UTC, GitHub ha servito errori e latenze su issue, pull request, API, Actions e Copilot. Sono 7 ore e 47 minuti. Nel punto peggiore falliva circa il 20 per cento delle richieste web e delle chiamate all'interfaccia di programmazione. Per il download degli archivi e dei contenuti grezzi si arrivava intorno al 50 per cento. È caduta anche l'autenticazione aziendale via SAML e OIDC, il che in molte imprese ha significato non riuscire nemmeno a entrare.

La causa immediata è una saturazione di rete sui bilanciatori di carico del data center di Central US. Un sidecar Istio, cioè il piccolo processo che affianca ogni servizio e ne gestisce il traffico di rete, ha raggiunto il proprio limite di richieste in parallelo. La politica di scalatura automatica avrebbe dovuto aggiungere capacità, però sorvegliava i limiti del servizio principale e non quelli del sidecar. Quattro nodi HAProxy hanno esaurito i loro limiti di flusso e da lì l'autenticazione ha cominciato a fallire ovunque. La ricostruzione tecnica sta nel thread di incidente pubblicato da GitHub, il resoconto di sintesi nel post firmato dal chief technology officer tre giorni dopo.

Il moltiplicatore stava sui portatili

Fin qui è un guasto di infrastruttura come tanti. Quello che viene dopo riguarda chi compra il software più di chi tiene su i server. Le risposte lente di un singolo endpoint interno hanno risvegliato un bug latente in Visual Studio Code. L'editor non riceveva risposta e ripresentava la richiesta. Poi di nuovo. Il traffico verso il Copilot Token Service, il servizio che rilascia i gettoni con cui l'assistente di codice si autentica, è passato da 7-9 mila richieste al secondo a un valore compreso fra 70 e 100 mila. Circa dieci volte il normale, prodotto dai client mentre il servizio stava già annaspando.

Un sistema in quelle condizioni non si riprende da solo. Gli ingegneri hanno ridotto i tentativi sul gateway con una modifica al codice e hanno fatto rispondere 403 dai bilanciatori a tutte le richieste in ingresso verso il Copilot Token Service, riaprendo poi il rubinetto un sito alla volta. È per questo che gran parte dei servizi era di nuovo in linea alle 16:36 UTC, Actions restava degradato fino alle 18:03 circa e il Copilot Token Service ha chiuso la partita alle 21:02.

C'è una ragione per cui a rientrare per ultima è stata proprio la funzione con l'intelligenza artificiale. Un assistente di codice non fa una chiamata ogni tanto come un gestionale. Chiede un gettone, lo rinnova, ricontrolla i permessi, ripete l'operazione a ogni sessione aperta su ogni macchina di ogni sviluppatore che lo usa. Quando milioni di client fanno insieme la stessa cosa in più, il fattore dieci non ha bisogno di un bug complicato per prodursi.

Cosa ammette GitHub

Non siamo riusciti a far crescere componenti critici prima che la domanda superasse la loro capacità.

Lo ha scritto il 20 agosto Vlad Fedorov, chief technology officer dell'azienda. Nello stesso testo ci sono i numeri che spiegano la pressione. I commit mensili sulla piattaforma sono passati da 1,4 miliardi ad aprile a 2,9 miliardi ad agosto. GitHub dichiara di aver aggiunto più di 3 milioni di core e 120 petabyte di storage veloce e di aver portato su Azure circa il 58 per cento del carico, contro il 12 per cento di maggio.

Raddoppiare il traffico in quattro mesi mentre si sposta metà della piattaforma su un'altra infrastruttura è un lavoro che poche aziende al mondo affrontano. Ammettere per iscritto di aver mancato una scalatura è più raro ancora. Conta però l'elenco dei rimedi. Non c'è nulla sui modelli. Ci sono limiti e budget di ripetizione coerenti fra i servizi, la revisione degli allarmi a bassa priorità sui componenti sensibili ai picchi, l'isolamento dei sistemi critici dalle dipendenze condivise, la correzione delle politiche di scalatura perché tengano conto dei limiti del sidecar. L'ultima voce riguarda il comportamento di Visual Studio Code.

Cosa cambia per chi firma

Un impegno di disponibilità al 99,9 per cento descrive il servizio del fornitore. Non descrive quanto durerà il fermo dentro l'azienda che lo usa, perché quel numero dipende anche da come reagisce agli errori il software installato in casa. Il 17 agosto la distanza fra le due durate è stata di oltre quattro ore.

Ho commesso lo stesso errore in piccolo. Un'automazione che riprovava una chiamata ogni cinque secondi senza attesa crescente, davanti a un rallentamento del fornitore, ha sfondato il limite di richieste e ha tenuto fuori l'integrazione per una ventina di minuti dopo che il servizio era già tornato normale. Il fornitore era a posto. Il pezzo scritto da me no.

Per chi compra un agente conversazionale o un'automazione la conseguenza è meno astratta di quanto sembri. Un sistema che di fronte a un errore insiste in silenzio trasforma un rallentamento di dieci minuti del fornitore in un fermo di un'ora per l'ufficio che lo usa. Nessuno se ne accorge, perché il sintomo assomiglia in tutto a un guasto del fornitore.

La mia posizione è che su integrazioni di questo tipo un tentativo solo, seguito da un errore dichiarato all'utente, valga più di cinque tentativi silenziosi. Chi la pensa diversamente ha un argomento serio. La stragrande maggioranza dei rallentamenti dura meno di un secondo, e un client che si arrende subito scarica sulla persona un fastidio che il software poteva assorbire da solo senza disturbare nessuno.

Dove finisce l'insistenza ragionevole

Il 17 agosto Visual Studio Code stava facendo esattamente quello per cui era stato scritto, cioè non mollare. Ha funzionato bene per anni proprio così. Il punto su cui la discussione resta aperta è dove finisca l'insistenza ragionevole di un client e dove cominci il danno al servizio da cui dipende, dato che chi scrive il client non vede mai il carico aggregato che il suo codice produce quando gira su qualche milione di macchine insieme.