Waar GitHub Daadwerkelijk Uitviel
Herkenbare situatie: je probeert code te pushen of acties te controleren, en krijgt stilte of een 500-fout als antwoord. Je gaat naar de officiële statuspagina, en alles straalt groen, met de melding "Alle Systemen Operationeel". Pas een half uur of een uur later verschijnt er een bescheiden banner over een incident.
Ik heb altijd amusant gevonden hoe grote platforms weten hoe ze uptime-statistieken kunnen "gladstrijken". Als je de officiële rapporten gelooft, is GitHub bijna altijd beschikbaar op 99,9%. Maar ontwikkelaars die de service elke dag gebruiken weten: de realiteit is veel prozaïscher. Het github-statuses project is een poging om de historische feiten recht te zetten en te laten zien hoe de beschikbaarheid er werkelijk uitzag voor het belangrijkste codeplatform.
Waar Dit Project Over Gaat
De repository-auteur besloot om de mooie grafieken niet zomaar te vertrouwen en creëerde de "ontbrekende statuspagina". Het is een archief dat gegevens verzamelt uit de Atom-feeds van GitHub en de echte chronologie van incidenten reconstrueert.
Het project is interessant omdat het niet alleen de huidige staat weerspiegelt—het bewaart geschiedenis. Als GitHub een oud incident verwijdert of de starttijd aanpast (wat gebeurt), bewaart deze repository het originele spoor. Het project is inmiddels opgemerkt door grote techpublicaties zoals The Register en populaire bloggers zoals Fireship en PrimeTime. Het lijkt erop dat het "vallende GitHub"-onderwerp een gevoelig punt is voor velen.
Hoe Het Onder De Motorkap Werkt
De basis is het Flat Data-concept. Gegevens worden opgehaald uit een externe bron, verwerkt en direct opgeslagen in de repository als eenvoudige tekstbestanden (JSON, CSV).
Een interessant detail: soms "vergeet" GitHub om aan te geven welke componenten werden getroffen in een incidentbeschrijving. Om dit probleem op te lossen, koppelde de auteur GLiNER2 aan—een klein named entity recognition (NER) model. Het analyseert de berichttekst en bepaalt waarover wordt gesproken: Actions, Copilot of API-problemen.
De tech stack ziet er zo uit:
- Python 3.11–3.13 voor extractiescripts.
- uv als de package manager (de auteur beveelt het sterk aan, en ik ben het ermee eens—het werkt razendsnel).
- GitHub Actions voor het automatiseren van gegevensverzameling.
- Een eenvoudige statische HTML/JS-website die de verzamelde gegevens visualiseert.
Wat Je Uit De Gegevens Kunt Halen
Als je de repository kloont, bevat de parsed/ folder al kant-en-klare gegevens. Maar als je zelf wilt experimenteren, kun je met de scripts:
- Alle incidenten voor een specifieke periode exporteren in JSONL-formaat.
- De gegevens verrijken met impactniveau-informatie—hiervoor gaat het script de specifieke incidentpagina's parsen.
- Een CSV genereren met downtimevensters, die je gemakkelijk in Excel of Grafana kunt laden om je eigen grafieken te maken.
Om dit alles te draaien heb je maar een paar commando's nodig:
uv venv --python 3.13
uv sync
uv run python scripts/extract_incidents.py --out my_data --enrich-impact
Waarom Dit Nuttig Is Voor Ontwikkelaars
Op het eerste gezicht lijkt het alsof het alleen een "muur van schande" is. Maar het project heeft best praktische toepassingen.
Ten eerste is het een geweldig voorbeeld van werken met ongestructureerde gegevens. Kijk hoe de auteur een ML-fallbackmechanisme implementeerde toen reguliere HTML-parsing faalde. In de code kun je zien hoe je confidence thresholds voor het model configureert en hoe je false positives uitfiltert.
Ten tweede, als je bij een bedrijf werkt waar GitHub-afhankelijkheid kritiek is (bijvoorbeeld, elke 5 minuten uitrollen via Actions), kunnen deze gegevens helpen om het bedrijf te overtuigen van de noodzaak van self-hosted runners of een backup-basis op GitLab/Bitbucket. Cijfers van een onafhankelijke bron zijn altijd overtuigender dan "nou, ik denk dat het vaak uitvalt".
Hoe Je De Resultaten Bekijkt
Het mooiste is dat je niets hoeft te configureren om de grafieken te bekijken. De repository heeft een site/ folder. Je kunt gewoon een lokale server draaien:
python -m http.server 8000
En open http://localhost:8000/site/. Je ziet tijdlijnen, uptime-percentages voor specifieke services (Actions, Pages, Copilot), en een gedetailleerde uitsplitsing per dag.
Het github-statuses project is niet zomaar een bug-archief. Het is een goed voorbeeld van hoe je met Python, een paar ML-bibliotheken en GitHub Actions een transparant monitorsysteem kunt creëren waar officiële bronnen liever over zwijgen.
Wie zou de repository moeten bekijken:
- Mensen die geïnteresseerd zijn in open data-verzameling en -analyse (Open Data).
- Ontwikkelaars die de uv-bibliotheek in een echt project willen uitproberen.
- SRE-engineers voor het inschatten van risico's van het gebruik van clouddiensten.
Het project leeft, gegevens worden regelmatig bijgewerkt, en de code is netjes genoeg geschreven om er in een avondje achter te komen. Je kunt zelfs proberen deze scripts aan te passen om andere diensten te monitoren die belangrijk voor je zijn.
Gerelateerde projecten