Red Squares, où les pannes de GitHub apparaissent comme des contributions
(red-squares.cian.lol)- Red Squares parodie le graphe des contributions par commits de GitHub et affiche les pannes de la plateforme GitHub.com avec des cases rouges au lieu des cases vertes
- Chaque case rouge représente une journée durant laquelle GitHub a subi une panne, et plus la couleur est foncée, plus la panne a duré longtemps ce jour-là
- Sur l’année écoulée, le temps d’indisponibilité total de GitHub est estimé à 32,5 jours
- Le nombre de jours ayant connu au moins un incident s’élève à 167 jours
- Le pire jour est le jeudi 30 avril 2026, avec 1,0 jour d’indisponibilité
1 commentaires
Réactions sur Hacker News
Chaque fois qu’un site de mèmes sur le vibe coding comme celui-ci apparaît, il y a sans fin des commentaires disant que la vraie cause n’est pas la charge, mais que l’équipe GitHub, la stack technique, Microsoft et Azure sont médiocres
Si on compare la page publique de statut de GitHub et celle d’Enterprise Cloud, les chiffres côté Enterprise sont bien meilleurs, et personnellement je ne me souviens même plus de la dernière panne qui m’a réellement empêché de travailler
Si le problème n’est pas lié à la charge, on devrait voir les mêmes soucis de disponibilité sur le produit Enterprise
Surtout quand il s’agit d’une entreprise disposant de plus de ressources que de nombreux pays et des meilleurs talents techniques du monde, la critique du système est tout à fait légitime
La stack technique de GitHub est réellement mauvaise, et cela fait longtemps qu’elle est défendue avec une certaine arrogance
Azure est une plateforme épouvantable qui est imposée de force aux équipes, et j’ai aussi vu une attitude défensive sur le choix de la base de données relationnelle ou la réécriture du frontend
Réécrire l’UI et pousser des outils d’IA alors qu’on n’arrive même pas à garder le site stable, c’est une perte de temps
Il ne s’agit pas d’attaquer des ingénieurs individuellement, mais de critiquer les choix de la direction d’un système devenu de fait un monopole grâce aux effets de réseau, qui privilégie les nouvelles fonctionnalités ou la satisfaction du propriétaire au produit principal
Comme cette page peut servir de preuve défavorable à l’entreprise, la comparaison n’a pas beaucoup de sens
En pratique, ce sont souvent de vraies pannes que le langage marketing appelle simplement « dégradation des performances », et une page de statut indépendante est bien plus utile
Ce n’est pas tous les jours, mais je me souviens à peine de la dernière semaine au travail passée sans contourner une panne
Dans la plupart des cas, on peut continuer à « travailler », mais des tâches qui auraient été buildées ou déployées dans le même temps sans incident prennent du retard, donc personnellement je suis affecté au moins une fois par semaine
Sinon, il faudrait au moins afficher en gros en haut un avertissement du type « usage réservé au loisir »
On peut répondre aux fils existants, mais pas en créer de nouveaux, et c’est aussi affiché sur la page de statut
Je ne comprends pas comment ça a pu passer en production, ni pourquoi cela dure depuis une heure
Et quel service de nous dire si gentiment qu’il faudra encore 3 à 4 heures pour corriger ça
Imputer à GitHub jusqu’aux baisses de performance de modèles externes comme Gemini 2.5 Pro, Grok Code Fast 1 in Copilot ou Claude Opus 4 ne me paraît pas très juste
J’ai l’impression que ce n’est pas un problème sur lequel GitHub peut faire quoi que ce soit
On efface la notion de gravité, puis on résume tout en « panne GitHub » ou en graphique de disponibilité
J’ai aussi des reproches à faire aux grosses pannes récentes de GitHub, mais voir se multiplier des sites conçus pour attirer l’attention et des posts sociaux qui brouillent la frontière entre une petite dégradation de service et une panne du site entier pour rendre ça plus dramatique et récolter recommandations, likes, karma et attention, ce n’est pas très réjouissant
On dirait surtout qu’ils voulaient rendre le graphique aussi rouge que possible
Nous exploitons un service bien plus petit que GitHub, mais nous avons prévu des chemins de secours avec plusieurs fournisseurs et plusieurs modèles
Le week-end est encore une frontière non explorée
Il y a encore de la marge pour s’étendre
Les pannes couvraient 62 % des jours de semaine et 11 % des week-ends, et pour Claude c’était similaire avec 92,5 % en semaine et 97,8 % le week-end
Le créneau dangereux va du mardi au jeudi, et le dimanche ressemble pratiquement à un autre service
https://www.aakash.io/tech-chase/github-and-claude-are-down-...
Je doute d’abord de l’exactitude de ce graphique
Il indique « 170 jours avec au moins un incident · pire journée jeudi 20 novembre 2025, 1,1 jour », et je ne vois pas comment le total d’une seule journée peut faire 1,1 jour
Même en survolant cette date, on ne voit pas la méthode de calcul interne, et un élément individuel apparaît à 1,3 heure
Le 19 novembre, il y a un incident affiché à 1,3 jour, mais le total est indiqué à 8,1 heures
Pour cette date, elle signale 24 heures de perturbation mineure
Ce site semble additionner le downtime de tous les services sur une journée, et dans ce cas la pire journée pourrait atteindre jusqu’à 10 jours de downtime en additionnant le downtime quotidien par grande catégorie
1: https://mrshu.github.io/github-statuses/
Je n’ai pas vérifié s’il y a réellement eu une panne ce jour-là, mais en supposant que les chiffres soient justes, 7,8 heures plus 1 jour donnent à peu près 1,3 jour
L’écart entre la page de statut officielle [0] et la page de statut tierce [1] est beaucoup trop grand
Si cela diffère autant de l’usage réel du produit, je me demande comment les clauses des accords de niveau de service peuvent être légales
J’aime GitHub et son service, mais chaque fois que le produit est en réalité en panne alors que la page de statut reste verte, quelque chose hurle en moi
[0] https://www.githubstatus.com/
[1] https://mrshu.github.io/github-statuses/
Dans mon précédent poste, nous avons subi de nombreuses pannes GitHub qui n’apparaissaient pas sur la page de statut officielle, et j’en avais gardé des traces via la recherche Slack
Ensuite, après discussion entre les responsables métier et l’account manager GitHub, nous avons obtenu quelques centaines de dollars de crédits
Mais ils se sont plaints que ces quelques centaines de dollars ne valaient pas le temps investi, donc la faible disponibilité de GitHub continue et rien ne change
À l’inverse, la page tierce considère même la panne ou le problème d’un modèle spécifique comme un problème GitHub, ce qui peut créer un écart avec l’usage réel
Il y a beaucoup moins de pannes le week-end
C’est parfait, de toute façon je n’avais pas l’intention de travailler à ce moment-là
Cette idée existe depuis longtemps
En janvier, j’ai construit ceci pour découper la disponibilité par catégorie d’incident
https://isgithubcooked.com
Le fait qu’il n’y ait presque pas de downtime le week-end donne un rendu assez proche du graphe de contributions, ce qui est drôle