L’historique du temps de disponibilité de GitHub

• Une page qui visualise le temps de disponibilité mensuel de GitHub de 2016 à 2026
  • Toutes les données sont basées sur des archives collectées depuis la page d’état officielle
• Une structure qui permet de distinguer le taux de disponibilité moyen (Average) et le détail des interruptions (Breakdown)
• Accès direct à la source des données d’origine (View source) depuis la page
• Un support de visualisation qui permet de vérifier d’un coup d’œil l’évolution de la stabilité du service sur le long terme
• Une présentation centrée sur la visualisation des données, sans analyse ni commentaire supplémentaires

[GN⁺]

Commentaires sur Hacker News

• Je me demandais si les données d’avant 2018 étaient vraiment exactes
  Je me souviens qu’il y avait déjà eu plusieurs pannes à l’époque
  Il est possible qu’ils aient commencé à utiliser leur système de suivi de l’uptime actuel à partir de ce moment-là

  • Les données proviennent de la page de statut officielle
    Mais cette page semblait davantage conçue pour le marketing/la communication que pour l’observation

• Personnellement, je trouve que cette page de statut alternative est meilleure
  Appelée « The Missing GitHub Status Page », elle montre de façon globale le taux de disponibilité sur les 90 derniers jours
  Il est actuellement à 90,84 %, légèrement mieux que les 90,00 % d’il y a quelques jours

  • La période récente a été assez chaotique
    Le taux de disponibilité de GitHub Actions en février 2026 est de 98 %, soit à peine un seul « 9 »
    À l’usage, j’ai l’impression que ça échoue 1 à 2 fois sur 50, soit environ 2 %
  • Ce type de chiffre agrégé ne semble pas être un indicateur très pertinent
    Par exemple, si OpenAI tombe en panne et que CoPilot ne fonctionne plus, peut-on vraiment considérer cela comme du downtime de GitHub ?
  • En réalité, les deux pages ne font qu’afficher les mêmes statistiques différemment
    On dirait que l’OP les a présentées de manière à mettre en avant les effets après le rachat par Microsoft
  • « 90 %, ça fait presque 5 semaines de downtime »
    C’est une blague, mais on pourrait dire que GitHub a désormais bien mérité ce niveau de « congés payés »

• Afficher ces données sans indiquer la date d’introduction des fonctionnalités est biaisé
  Par exemple, GitHub Actions a été lancé en août 2019, donc il est normal qu’il n’y ait aucun downtime avant cette date

  • Dans « Breakdown », on peut cliquer sur « Actions » pour masquer cet élément
  • En regardant la page détaillée, l’ampleur de chaque service diminue, mais la tendance générale reste la même
  • Le pire, c’est que c’est affiché comme « 100% uptime » même pour une période où le service n’existait pas

• Moi aussi, j’avais fait le même graphique avec Claude il y a quelques semaines
  Je m’attendais à une forte baisse avant/après le rachat par Microsoft, mais en réalité il y avait depuis longtemps un schéma de pannes irrégulier
  L’idée selon laquelle c’était plus stable avant le rachat est intéressante, mais à l’époque il n’y avait pas de produit comme Actions
  Pour les services qui existaient déjà (API, Git ops, Pages, etc.), cela peut plutôt s’expliquer par une meilleure observabilité

  • On a l’impression que le cauchemar, en termes d’exploitation et de disponibilité, a commencé après le lancement d’Actions
    Ensuite, les problèmes se sont propagés à des zones auparavant stables comme Issues ou les PR
  • Personnellement, je pense que GitHub Actions devrait tout simplement disparaître
    Git a été conçu à l’origine pour faire une seule chose correctement, et lui greffer plein de fonctionnalités inutiles a été une grosse erreur

• Si certains cherchent une explication, cet article de The New Stack pourrait en donner une

  • Tout à fait d’accord. Dans notre équipe, les pannes Azure et les pannes GitHub surviennent presque en même temps
    C’est devenu une sorte de mème
  • Cela dit, je ne pense pas qu’on puisse expliquer à lui seul plus de 6 ans de faible disponibilité
    Ils auraient dû tester suffisamment dans un environnement séparé et migrer vers Azure sur une période plus courte

• Actuellement, la fusion des PR ne fonctionne pas
  L’état du problème peut être vérifié sur la page d’incident GitHub Status

• Je me souviens qu’autrefois on voyait souvent la page d’erreur avec la licorne
  À l’époque, la page de statut n’était probablement pas mise à jour très souvent

  • La licorne semblait être une erreur propre aux pages web
    Des services comme l’API Git pouvaient tomber séparément, et cela n’apparaissait sur la page de statut qu’avec un certain décalage

• Aujourd’hui, on dirait que l’historique de downtime de GitHub est pire que celui de mon serveur perso
  Pourtant, je redémarre souvent ou j’arrête des services pour faire des expériences

  • Et malgré ça, on continue de payer
    Comme si on croyait encore qu’un certain niveau de QoS était maintenu malgré la baisse de qualité
  • Même mon petit VPS est mesurablement plus stable que GitHub

• Je ne suis pas spécialement là pour défendre GitHub, mais ce graphique a un axe trompeur
  Il zoome uniquement sous 99,5 %, donc ça a l’air bien pire que la réalité

  • Mais si on part de 0, on ne voit plus la différence entre un bon service et un mauvais
    Le SLA en entreprise est de 99,9 %, et le bas du graphique montre 5 fois plus de downtime que ça
    Donc ce n’est pas juste une impression de médiocrité : c’est réellement mauvais
  • Le graphique ne prend pas en compte la charge (load)
    Il faut aussi considérer qu’avant le rachat par Microsoft, il n’y avait qu’un seul dépôt privé autorisé
  • Il n’est pas nécessaire de tracer un graphique d’uptime à partir de 0
    Montrer uniquement la plage des 99 % est raisonnable
    Une échelle logarithmique me semblerait au contraire excessive

• J’utilise GitHub Pages pour déployer un site web, donc j’ai regardé séparément la disponibilité de l’hébergement statique
  Selon cette analyse de blog, GH Pages obtient de très bons résultats dans cette catégorie
  Mais le mérite revient sans doute surtout au CDN Fastly