GitHub Actions e Pages colpiti da un grave guasto, recupero in corso

GitHub Actions e Pages colpiti da un grave guasto, recupero in corso

I servizi di automazione e hosting di GitHub hanno subito un significativo guasto il 6 agosto 2026, causando interruzioni diffuse per gli sviluppatori che si affidano a pipeline CI/CD e hosting di siti statici. L'incidente, iniziato alle 15:22 UTC, è rapidamente degenerato colpendo molteplici servizi interconnessi, tra cui Copilot e GitHub Enterprise Importer, prima che venisse raggiunto un recupero parziale. L'azienda ha da allora condiviso una cronologia dettagliata e le fasi di recupero, ma l'evento evidenzia la fragilità delle infrastrutture critiche di sviluppo.

Il guasto è iniziato con segnalazioni di prestazioni degradate per GitHub Actions, seguite entro pochi minuti dalla conferma di disponibilità ridotta. Gli utenti hanno rapidamente riscontrato esecuzioni di workflow fallite, avvii ritardati dei job ed errori dall'API REST di Actions. È stata segnalata anche una limitazione imprevista della frequenza, aumentando la frustrazione. Gli ingegneri di GitHub hanno identificato la fonte dell'interruzione e hanno iniziato a implementare mitigazioni, ma la situazione è rimasta irrisolta per ore.

Effetti a catena: Pages, Copilot e Enterprise Importer

Con il progredire dell'incidente, l'impatto si è esteso oltre Actions. GitHub Pages, il servizio di hosting di siti statici, è stato aggiunto all'elenco dei sistemi colpiti, con utenti che hanno riscontrato prestazioni degradate. Più sorprendentemente, la revisione del codice di Copilot e l'agente di codifica di Copilot sono stati anch'essi colpiti, insieme alle migrazioni che utilizzano GitHub Enterprise Importer. Le consegne dei webhook sono state ritardate e i runner ospitati hanno affrontato vincoli di capacità, causando l'accodamento dei job per periodi prolungati o il loro timeout completo.

La natura interconnessa di questi servizi sottolinea la complessità dell'infrastruttura di GitHub. Un problema in un'area può propagarsi, colpendo strumenti su cui gli sviluppatori fanno affidamento per le operazioni quotidiane. Per molti team, ciò ha significato rilasci bloccati, distribuzioni ritardate e flussi di lavoro di sviluppo bloccati.

Cronologia del recupero e problemi persistenti

La pagina di stato di GitHub fornisce una cronologia dettagliata degli sforzi di recupero. Entro le 20:34 UTC, l'azienda ha notato che la capacità rimaneva limitata e che i runner self-hosted potevano riscontrare errori di registrazione. Alle 21:30 UTC, i trigger dei webhook erano ancora limitati, elaborando solo circa il 15% degli eventi, con tassi di successo dei job al 65%. La situazione è migliorata gradualmente, con tassi di successo saliti al 97% entro le 22:18 UTC e al 99% entro le 23:13 UTC.

Tuttavia, anche dopo che l'incidente è stato segnato come risolto alle 02:04 UTC del 7 agosto, sono rimasti problemi persistenti. Alcuni pod del controller dei runner di Actions (ARC) erano bloccati in uno stato inattivo, richiedendo un intervento manuale. Agli utenti è stato consigliato di eliminare tali pod utilizzando kubectl o di ridistribuire la loro applicazione ARC. Inoltre, alcuni eventi di attivazione dei workflow, come gli eventi push e pull request, non sono stati elaborati durante l'incidente e non possono essere riprodotti automaticamente, il che significa che gli utenti potrebbero dover riattivare manualmente i workflow.

Causa principale e prevenzione futura

Sebbene GitHub non abbia divulgato la causa principale, l'azienda ha dichiarato che verrà condivisa un'analisi dettagliata. L'incidente ha coinvolto l'assegnazione di job non validi ai runner, portando a un arretrato che ha ritardato l'elaborazione. L'azienda ha implementato correzioni e meccanismi di recupero automatico nelle versioni future di Actions Runner e Actions Runner Controller per prevenire problemi simili.

Questo guasto è un promemoria del ruolo critico che GitHub svolge nell'ecosistema dello sviluppo software. Per molte organizzazioni, GitHub Actions è la spina dorsale della loro pipeline CI/CD e qualsiasi interruzione può avere significative implicazioni aziendali. Il fatto che Copilot e Pages siano stati anch'essi colpiti evidenzia la necessità di una solida risposta agli incidenti e di una comunicazione efficace, che GitHub ha fornito attraverso la sua pagina di stato.

Mentre i team di sviluppo si riprendono da questo incidente, dovrebbero rivedere i propri processi per gestire tali interruzioni. Implementare strategie di fallback, monitorare le pagine di stato e comprendere i limiti dei servizi gestiti sono tutti passaggi prudenti. L'impegno di GitHub a condividere un'analisi della causa principale sarà prezioso per la comunità, contribuendo a creare fiducia e migliorare la resilienza.

Per ora, il servizio è stabile, ma l'incidente serve come un duro promemoria delle dipendenze che lo sviluppo software moderno ha dagli strumenti basati su cloud. La capacità di adattarsi e recuperare rapidamente è essenziale, e la risposta di GitHub, sebbene non perfetta, ha dimostrato un impegno per la trasparenza e la risoluzione.