Là où GitHub a réellement connu des pannes

Situation familière : vous essayez de pousser du code ou de vérifier des actions, et vous obtenez le silence ou une erreur 500 en réponse. Vous vous rendez sur la page de statut officielle, et tout brille en vert, indiquant « Tous les systèmes opérationnels ». Ce n'est qu'une demi-heure ou une heure plus tard qu'une modeste bannière concernant un incident apparaît.

J'ai toujours trouvé amusant comment les grandes plateformes savent « lisser » les statistiques de disponibilité. Si vous faites confiance aux rapports officiels, GitHub est presque toujours disponible à 99,9 %. Mais les développeurs qui utilisent le service chaque jour le savent : la réalité est beaucoup plus prosaïque. Le projet github-statuses est une tentative de rectifier l'historique et de montrer à quoi ressemblait réellement la disponibilité pour la forge de code principale.

De quoi parle ce projet

L'auteur du dépôt a décidé de ne pas prendre les beaux graphiques au pied de la lettre et a créé la « page de statut manquante ». C'est une archive qui collecte des données à partir des flux Atom de GitHub et reconstruit la véritable chronologie des incidents.

Le projet est intéressant parce qu'il ne se contente pas de refléter l'état actuel — il stocke l'historique. Si GitHub supprime un ancien incident ou ajuste son heure de début (ce qui arrive), ce dépôt conserve la trace originale. Le projet a déjà été remarqué par des grandes publications tech comme The Register et des bloggers populaires comme Fireship et PrimeTime. Il semble que le sujet des « pannes de GitHub » ait été un point sensible pour beaucoup.

Comment ça fonctionne en coulisses

Le fondement est le concept de Flat Data. Les données sont extraites d'une source externe, traitées et enregistrées directement dans le dépôt sous forme de fichiers texte simples (JSON, CSV).

Un détail intéressant : parfois GitHub « oublie » de préciser quels composants ont été affectés dans la description d'un incident. Pour résoudre ce problème, l'auteur a connecté GLiNER2 — un petit modèle de reconnaissance d'entités nommées (NER). Il analyse le texte du message et détermine de quoi il est question : des problèmes avec Actions, Copilot ou l'API.

La pile technique ressemble à ceci :

• Python 3.11–3.13 pour les scripts d'extraction.
• uv comme gestionnaire de paquets (l'auteur le recommande vivement, et je suis d'accord — ça fonctionne à une vitesse éclair).
• GitHub Actions pour automatiser la collecte de données.
• Un simple site web HTML/JS statique qui visualise les données collectées.

Ce que vous pouvez extraire des données

Si vous clonez le dépôt, le dossier parsed/ contient déjà des données prêtes à l'emploi. Mais si vous voulez vous amuser vous-même, les scripts vous permettent de :

1. Exporter tous les incidents pour une période donnée au format JSONL.
2. Enrichir les données avec des informations sur le niveau d'impact — pour cela, le script va analyser les pages d'incidents spécifiques.
3. Générer un CSV avec les fenêtres d'indisponibilité, que vous pouvez facilement importer dans Excel ou Grafana pour construire vos propres graphiques.

Pour exécuter tout cela, il suffit de quelques commandes :

uv venv --python 3.13
uv sync
uv run python scripts/extract_incidents.py --out my_data --enrich-impact

Pourquoi c'est utile pour les développeurs

À première vue, cela ressemble à un simple « mur de la honte ». Mais le projet a des applications assez pratiques.

Premièrement, c'est un excellent exemple de travail avec des données non structurées. Jetez un œil à la façon dont l'auteur a implémenté un mécanisme de repli ML lorsque l'analyse HTML classique échoue. Dans le code, vous pouvez voir comment configurer les seuils de confiance pour le modèle et comment filtrer les faux positifs.

Deuxièmement, si vous travaillez dans une entreprise où la dépendance à GitHub est critique (par exemple, un déploiement via Actions toutes les 5 minutes), ces données peuvent aider à convaincre la direction de la nécessité de mettre en place des runners auto-hébergés ou d'un plan B sur GitLab/Bitbucket. Les chiffres d'une source indépendante sont toujours plus convaincants que « eh bien, je pense que ça tombe souvent en panne ».

Comment visualiser les résultats

Le meilleur dans tout ça, c'est que vous n'avez rien à configurer pour voir les graphiques. Le dépôt contient un dossier site/. Vous pouvez simplement lancer un serveur local :

python -m http.server 8000

Et ouvrir http://localhost:8000/site/. Vous verrez des chronologies, des pourcentages de disponibilité pour des services spécifiques (Actions, Pages, Copilot), et une ventilation détaillée par jour.

Le projet github-statuses n'est pas qu'une simple archive de bugs. C'est un bon exemple de comment, avec Python, quelques bibliothèques ML et GitHub Actions, vous pouvez créer un système de surveillance transparent là où les sources officielles préfèrent rester silencieuses.

Qui devrait consulter le dépôt :

• Ceux qui s'intéressent à la collecte et l'analyse de données ouvertes (Open Data).
• Les développeurs qui veulent essayer la bibliothèque uv dans un projet réel.
• Les ingénieurs SRE pour évaluer les risques liés à l'utilisation de services cloud.

Le projet est vivant, les données sont mises à jour régulièrement, et le code est suffisamment propre pour être compris en une soirée. Vous pouvez même essayer d'adapter ces scripts pour surveiller d'autres services qui vous tiennent à cœur.