Dove GitHub È Davvero Andato Giù
Situazione familiare: provi a fare push del codice o a controllare le actions, e ottieni silenzio o un errore 500 in risposta. Vai sulla pagina di stato ufficiale, e tutto è verde brillante, con scritto "All Systems Operational". Solo mezz'ora o un'ora dopo appare un modesto banner sull'incidente.
Ho sempre trovato divertente come le piattaforme principali sappiano "livellare" le statistiche di uptime. Se ti fidi dei rapporti ufficiali, GitHub è quasi sempre disponibile al 99,9%. Ma gli sviluppatori che usano il servizio ogni giorno sanno: la realtà è molto più prosaica. Il progetto github-statuses è un tentativo di riportare la verità storica e mostrare come l'effettiva disponibilità si è presentata per il principale code forge.
Di cosa tratta questo progetto
L'autore del repository ha deciso di non prendere per buoni i grafici eleganti e ha creato la "pagina di stato mancante". È un archivio che raccoglie i dati dai feed Atom di GitHub e ricostruisce la vera cronologia degli incidenti.
Il progetto è interessante perché non si limita a riflettere lo stato attuale—memorizza la cronologia. Se GitHub elimina un incidente vecchio o modifica l'orario di inizio (cosa che succede), questo repository conserva la traccia originale. Il progetto è già stato notato da importanti pubblicazioni tech come The Register e blogger popolari come Fireship e PrimeTime. Sembra che l'argomento "GitHub che cade" sia stato un punto dolente per molti.
Come funziona sotto il cofano
Il fondamento è il concetto di Flat Data. I dati vengono recuperati da una fonte esterna, elaborati e salvati direttamente nel repository come semplici file di testo (JSON, CSV).
Un dettaglio interessante: a volte GitHub "dimentica" di specificare quali componenti sono stati coinvolti in una descrizione di incidente. Per risolvere questo problema, l'autore ha collegato GLiNER2—un piccolo modello di named entity recognition (NER). Analizza il testo del messaggio e determina di cosa si sta parlando: problemi di Actions, Copilot o API.
Il tech stack è il seguente:
- Python 3.11–3.13 per gli script di estrazione.
- uv come package manager (l'autore lo consiglia strongly, e sono d'accordo—funziona in modo lightning fast).
- GitHub Actions per automatizzare la raccolta dei dati.
- Un semplice sito web statico HTML/JS che visualizza i dati raccolti.
Cosa puoi estrarre dai dati
Se cloni il repository, la cartella parsed/ contiene già dati pronti all'uso. Ma se vuoi giocarci tu stesso, gli script ti permettono di:
- Esportare tutti gli incidenti per un periodo specifico in formato JSONL.
- Arricchire i dati con informazioni sul livello di impatto—per questo, lo script va e analizza le pagine specifiche degli incidenti.
- Generare un CSV con le finestre di downtime, che puoi facilmente importare in Excel o Grafana per creare i tuoi grafici.
Per eseguire tutto questo bastano solo un paio di comandi:
uv venv --python 3.13
uv sync
uv run python scripts/extract_incidents.py --out my_data --enrich-impact
Perché è utile per gli sviluppatori
A prima vista sembra solo un "muro della vergogna". Ma il progetto ha applicazioni piuttosto pratiche.
Prima di tutto, è un ottimo esempio di lavoro con dati non strutturati. Dai un'occhiata a come l'autore ha implementato un meccanismo di fallback ML quando il parsing HTML normale fallisce. Nel codice puoi vedere come configurare le soglie di confidenza per il modello e come filtrare i falsi positivi.
Secondo, se lavori in un'azienda dove la dipendenza da GitHub è critica (per esempio, deploy tramite Actions ogni 5 minuti), questi dati possono aiutarti a giustificare al business la necessità di implementare self-hosted runners o un airfield di backup su GitLab/Bitbucket. Numeri da una fonte indipendente sono sempre più convincenti di "beh, penso che cada spesso".
Come visualizzare i risultati
La parte migliore è che non devi configurare nulla per vedere i grafici. Il repository ha una cartella site/. Puoi semplicemente eseguire un server locale:
python -m http.server 8000
E apri http://localhost:8000/site/. Vedrai timeline, percentuali di uptime per servizi specifici (Actions, Pages, Copilot) e un'analisi dettagliata per giorno.
Il progetto github-statuses non è solo un archivio di bug. È un buon esempio di come con Python, un paio di librerie ML e GitHub Actions, puoi creare un sistema di monitoraggio trasparente dove le fonti ufficiali preferiscono tacere.
Chi dovrebbe controllare il repository:
- Chi è interessato alla raccolta e analisi di dati aperti (Open Data).
- Sviluppatori che vogliono provare la libreria uv in un progetto reale.
- Ingegneri SRE per valutare i rischi dell'uso di servizi cloud.
Il progetto è vivo, i dati vengono aggiornati regolarmente e il codice è scritto in modo abbastanza pulito da capirlo in una serata. Puoi anche provare ad adattare questi script per monitorare altri servizi che ti interessano.
Progetti correlati