Mise à jour sur la disponibilité de GitHub
(github.blog)- Après deux incidents récents, GitHub a fait de la disponibilité sa priorité absolue et revoit son infrastructure ainsi que son architecture pour suivre l’explosion des charges de travail de développement et des agentic development workflows
- Un simple pull request peut mobiliser un large ensemble de composants, des dépôts Git à Actions, la recherche, les notifications, les autorisations, les webhooks, les API, les tâches en arrière-plan, les caches et les bases de données. À grande échelle, de petites inefficacités peuvent se transformer en engorgement des files d’attente et en propagation des dépendances
- À court terme, l’entreprise se concentre sur la migration du backend des webhooks, la refonte du cache des sessions utilisateur, l’ajustement des flux d’authentification et d’autorisation, ainsi que l’extension de la capacité de calcul sur Azure afin de réduire les goulets d’étranglement et la charge sur les bases de données
- À long terme, elle améliore la résilience et la flexibilité via l’isolation des services critiques, la réduction des points uniques de défaillance, la migration d’une partie du monolithe Ruby vers Go, le passage au public cloud et la mise en place d’une trajectoire multi cloud
- Ni la régression de merge queue du 23 avril ni la surcharge d’Elasticsearch du 27 avril n’ont entraîné de perte de données, et GitHub renforce aussi sa transparence en ajoutant des métriques de disponibilité à sa status page et en élargissant la publication des incidents, y compris les plus modestes
Contexte de la réponse sur la disponibilité
- GitHub fait le point sur ses travaux d’amélioration de la disponibilité et de la fiabilité après deux incidents récents
- Depuis octobre 2025, l’entreprise met en œuvre un plan d’augmentation de capacité par 10 ; en février 2026, il est devenu clair qu’il fallait concevoir les systèmes en partant d’une hypothèse de taille 30 fois supérieure à l’actuelle
- L’évolution des modes de développement logiciel constitue le principal facteur de fond, et les agentic development workflows se sont accélérés brutalement à partir du second semestre 2025
- La création de dépôts, l’activité autour des pull requests, l’usage des API, l’automatisation et les charges de travail liées aux grands dépôts augmentent tous rapidement
Les contraintes structurelles révélées par le passage à l’échelle
- Un pull request peut à lui seul solliciter les dépôts Git, les mergeability checks, la branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches et databases
- À grande échelle, même de faibles inefficacités s’accumulent et peuvent provoquer un engorgement des files d’attente, un report de charge des cache misses vers les bases de données, des retards d’indexation, une amplification du trafic de retry et des effets en chaîne dus à des dépendances lentes sur plusieurs produits
- L’ordre des priorités est désormais le suivant : la disponibilité d’abord, puis la capacité, puis les nouvelles fonctionnalités
- La réduction du travail inutile, l’amélioration des caches, l’isolation des services critiques, la suppression des points uniques de défaillance et la migration des chemins sensibles aux performances vers des systèmes dédiés avancent en parallèle
- L’objectif clé est de réduire les couplages cachés, de limiter le blast radius et d’assurer un graceful degradation afin qu’une pression exercée sur un sous-système ne fasse pas tomber l’ensemble
Améliorations actuellement en cours
- À court terme, l’accent est mis sur la résolution des goulets d’étranglement qui sont apparus plus vite que prévu
- GitHub a déplacé les webhooks vers un backend hors de MySQL, repensé le cache des sessions utilisateur et revu les flux d’authentification et d’autorisation, ce qui réduit fortement la charge sur les bases de données
- L’utilisation de la migration vers Azure a également permis d’obtenir davantage de ressources de calcul
- La suite des travaux se concentre sur l’isolation des services critiques comme Git et GitHub Actions, ainsi que sur la réduction des points uniques de défaillance
- Une analyse fine des dépendances et des couches de trafic a permis d’identifier ce qu’il fallait isoler, et les mesures sont appliquées par ordre de risque afin de minimiser l’impact de différents types d’attaques sur le trafic légitime
- Les travaux visant à migrer certaines parties du code sensibles à la performance ou à l’échelle du monolithe Ruby vers Go s’accélèrent également
- Alors que GitHub poursuivait déjà la transition de petits datacenters internes vers le public cloud, l’entreprise a aussi commencé à préparer sur le long terme une trajectoire multi cloud
- Cette initiative de long terme est nécessaire pour obtenir à l’avenir la résilience, la faible latence et la flexibilité requises
Réponse aux grands dépôts et à merge queue
- Parmi les défis de montée en charge encore plus difficiles que l’augmentation du nombre de dépôts, GitHub cite la croissance des grands monorepos
- Au cours des trois derniers mois, l’entreprise a fortement accru ses investissements pour répondre à cette tendance, à la fois côté système Git et côté expérience pull request
- Des travaux sont également en cours autour de la conception de nouvelles API pour améliorer encore l’efficacité et la capacité, et seront présentés dans un billet de blog séparé
- GitHub investit aussi dans l’optimisation du fonctionnement de merge queue, un point crucial pour les dépôts qui voient passer des milliers de pull requests par jour
Incident récent 1 : problème de merge queue le 23 avril
- Le 23 avril, une régression du fonctionnement de merge queue pour les pull requests s’est produite
- Dans merge queue avec la stratégie squash merge, lorsqu’un merge group contenait plus d’un pull request, un merge commit incorrect était généré
- Dans les cas affectés, les fusions suivantes pouvaient alors involontairement annuler des modifications introduites par des pull requests précédemment fusionnées ainsi que par des commits existants
- Pendant la fenêtre d’impact, 658 dépôts et 2 092 pull requests ont été touchés
- Les chiffres initiaux avaient été volontairement prudents, ce qui explique qu’ils aient d’abord été communiqués légèrement au-dessus de ce total
- Les pull requests fusionnées en dehors de merge queue n’ont pas été affectées, et les groupes merge queue utilisant les stratégies merge ou rebase ne l’ont pas été non plus
- Aucune donnée n’a été perdue. Tous les commits sont restés stockés dans Git
- En revanche, l’état de la branche par défaut des dépôts touchés était incorrect, et il n’était pas possible de restaurer automatiquement et en toute sécurité tous les dépôts
- incident root cause analysis : des détails supplémentaires sont disponibles
- Cet incident a mis en évidence plusieurs défaillances de processus, et GitHub est en train de modifier ces processus afin d’éviter qu’un problème du même type ne se reproduise
Incident récent 2 : problème lié à la recherche le 27 avril
- Le 27 avril, le sous-système Elasticsearch chargé de plusieurs expériences basées sur la recherche a connu une panne
- Le périmètre d’impact comprenait certaines interfaces de recherche liées aux pull requests, aux issues et aux projects
- L’analyse de la cause racine n’est pas encore finalisée et sera publiée prochainement
- D’après les éléments disponibles à ce stade, le cluster s’est retrouvé en situation de surcharge, ce qui l’a empêché de renvoyer des résultats de recherche
- Parmi les causes possibles de cette surcharge, la piste d’une attaque de botnet reste ouverte, mais l’analyse n’est pas encore terminée
- Aucune donnée n’a été perdue, et les opérations Git ainsi que les API n’ont pas été affectées
- En revanche, certaines interfaces dépendant de la recherche n’ont affiché aucun résultat, ce qui a provoqué une forte confusion
- Ce système faisait partie des zones où l’isolation complète destinée à éliminer les points uniques de défaillance n’était pas encore achevée ; jusque-là, les risques d’autres zones étaient jugés plus prioritaires
- GitHub applique maintenant la même analyse des dépendances et le même travail de réduction du blast radius pour diminuer la probabilité et l’impact de ce type de défaillance
Renforcement de la transparence sur les incidents
- Il est devenu évident que les clients attendaient davantage de transparence pendant les incidents
- GitHub a récemment mis à jour sa status page afin d’y inclure des métriques de disponibilité
- L’entreprise a décidé de publier sur cette page non seulement les incidents majeurs, mais aussi les incidents mineurs, afin que les utilisateurs n’aient pas à deviner si un problème vient de chez eux ou de GitHub
- La manière de classer les incidents continue également d’être améliorée pour rendre leur ampleur et leur portée plus faciles à comprendre
- GitHub travaille aussi à améliorer la façon dont les clients peuvent partager des signaux et signaler des problèmes pendant un incident
Engagements pour la suite
- GitHub s’engage à améliorer la disponibilité, à renforcer la résilience, à se mettre à l’échelle pour répondre aux volumes futurs du développement logiciel et à communiquer avec davantage de transparence
- Le nombre de dépôts affectés par l’incident du 23 avril a été mis à jour au 28 avril 2026
1 commentaires
Commentaires de Hacker News
GitHub a déjà subi des dizaines d’incidents rien que cette année, et sa disponibilité comme sa fiabilité se sont visiblement dégradées par rapport à l’an dernier.
À ce stade, c’est assez grave pour qu’on puisse faire tourner des dashboards et des heatmaps, et j’ai l’impression que l’instabilité de GitHub est en train de devenir un mème sur des sites comme HN ou Reddit.
Malgré ça, dire que les priorités sont "availability, capacity, new features" montre une lecture de la réalité bien trop relâchée.
Là, les priorités 1, 2 et 3 devraient toutes être availability, et pendant au moins 6 mois il ne faudrait parler de rien d’autre que de corriger ça.
Il y a 6 mois, ils disaient que la migration vers Azure était la priorité absolue et qu’ils repoussaient donc le développement de fonctionnalités, et maintenant ils disent que la disponibilité est la priorité absolue ; ça manque franchement de cohérence.
À l’époque, ils expliquaient que les contraintes de capacité du datacenter de Virginie étaient "existential" à cause de la demande liée à l’IA et à Copilot, donc voir qu’ils boitent toujours sur le même problème est encore plus sidérant.
Ils disent avoir repoussé le développement produit, mais de nouvelles fonctionnalités et des changements d’UI continuent d’arriver chaque semaine, et ils ont encore modifié récemment la vue unifiée des issues.
Qu’une entreprise disposant des ressources de Microsoft continue à trébucher au même endroit est difficile à croire, et la stratégie consistant à racheter des services populaires pour développeurs puis à tous les migrer vers la même plateforme ne paraît pas rassurante.
Dans une grande organisation d’ingénierie, les priorités ne sont pas forcément exclusives, et les équipes qui ne contribuent pas directement à la priorité principale peuvent continuer à travailler sur d’autres fonctionnalités.
https://news.ycombinator.com/item?id=47912521
Du matériel dédié est plus prévisible que le cloud, et une décision du genre "n’allons pas sur Azure, achetons plutôt quelques racks de plus" n’était peut-être pas du ressort de la direction de GitHub.
GitHub n’est pas un site à refondre toutes les 5 minutes, et on a parfois l’impression que des managers poussent de nouvelles fonctionnalités juste pour justifier leur existence.
Au final, plus ils cassent de choses, plus cela produit l’effet inverse de celui recherché pour attirer les utilisateurs.
La recherche a aussi été fortement dégradée, et comme pour Google Search ou YouTube, je ne comprends pas pourquoi tout le monde s’acharne à casser une recherche qui fonctionnait très bien.
En plus, Microsoft a à la fois Azure DevOps, qui semble quasiment abandonné, et GitHub, et je déteste les systèmes de tickets des deux.
J’en avais déjà assez de Jira, avec ses réglages différents d’un projet à l’autre, mais on en vient maintenant à dire : "finalement, Jira me manque presque".
Ce texte donne l’impression d’être difficile à lire sérieusement.
Des graphiques sans légendes avec de gros chiffres, des priorités qui ne collent pas à l’expérience réelle, et une attitude qui ne reconnaît pas honnêtement l’uptime catastrophique des 12 derniers mois : tout ça est très agaçant.
Il manque bien les labels de l’axe en bas à gauche, mais l’idée principale — une accélération très rapide de la croissance entre 2023 → 2024 → 2025 → 2026 — passe quand même.
On peut lire ça comme l’annonce qu’au début ou à la fin de 2026, la croissance sera supérieure à celle des 3 années précédentes réunies, et même sans les chiffres de l’axe, on voit la tendance générale.
Il faut supposer qu’il s’agit d’un graphe linéaire, mais vu le contexte, cette hypothèse ne paraît pas excessive.
Pour une entreprise qui subit une croissance bien supérieure au plan prévu, des problèmes de capacité sont inévitables, et il semble qu’ils aient désormais besoin d’aller au-delà du simple ajout de matériel pour travailler sur l’efficacité du backend.
Les objectifs qu’ils ont écrits visent d’ailleurs globalement cela.
https://x.com/kdaigle/status/2040164759836778878
Je ne sais pas si c’est l’idée d’une croissance exponentielle qui paraît peu crédible, ou si certains considèrent qu’une croissance annuelle x10 n’a rien de très difficile.
https://damrnelson.github.io/github-historical-uptime/
La phrase « we started our multi cloud journey » donne l’impression que Microsoft reconnaît de fait qu’il n’arrive pas à obtenir, avec Azure seul, le niveau de fiabilité souhaité.
Cela peut aider à limiter le churn.
À l’origine, l’objectif était une exploitation avec très peu d’intervention humaine, alors qu’aujourd’hui quelqu’un attache un câble série à un rack ou à une VM et intervient directement comme procédure courante.
Je ne retrouve plus le lien pour le moment.
C’est entre 9 h et 11 h du matin, heure du Pacifique, du lundi au jeudi, qu’il y a le plus de lecteurs actifs ; le week-end la concurrence est plus faible, mais l’engagement aussi.
Le CTO de GitHub siège aussi au conseil d’administration de Codepath.org, où il est question de « former la première génération AI-native d’ingénieurs, de CTO et de fondateurs », et avec ça on commence à voir d’où vient une partie du problème.
D’après ce que je constate, la stabilité de GitHub s’est nettement dégradée, et récemment il est même devenu difficile de faire confiance aux données affichées sur le web.
Depuis hier, plusieurs collègues et moi avons constaté que, sur plusieurs dépôts, la liste des PR s’affiche de manière incomplète.
Par exemple, sur https://github.com/gap-system/gap/pulls, l’onglet affiche « Pull requests 78 », mais la vue liste ne montre que « 35 open ».
Le nombre 78 est pourtant bien correct, comme on peut aussi le vérifier avec
gh pr list, et malgré cela https://www.githubstatus.com continue d’indiquer « all systems operational ».La liste apparaît bien en CLI, mais tout disparaît sur le parcours web qui passe par la recherche.
Le support a reconnu le problème, mais depuis plus rien, et la page de statut ne mentionne toujours rien à part un incident du 27 qui semble peut-être lié.
Sur certains dépôts, le problème semble avoir été résolu entre-temps, mais il reste reproductible sur plusieurs orgs et repos.
https://github.com/orgs/community/discussions/193388
J’ai fini par retrouver les PR manquantes en fouillant dans la page des branches.
Ce n’est peut-être pas un bug au sens strict, mais plutôt une très mauvaise décision produit pour réduire la charge sur l’infrastructure.
Le fait qu’ils aient publié des données sur les nouveaux repo/issues/commits de ces dernières années était tout de même intéressant.
Comme beaucoup le soupçonnaient déjà de l’extérieur, cela confirme que les agents imposent à GitHub une charge supplémentaire soudaine et importante.
Servir une base d’utilisateurs déjà énorme tout en connaissant une croissance exponentielle digne d’une startup fait forcément de vous une cible, et il ne doit pas être facile pour l’organisation de bouger vite.
À l’inverse, ils ont aussi bien plus de talents, d’infrastructure et d’argent qu’une startup.
Il n’y a qu’un graphique sans légende et les chiffres de pic actuels.
Je ne comprends pas du tout ce qu’ils ont fabriqué avec ces graphiques ; on dirait presque une impression artistique.
En regardant le graphe des commits, on ne voit pas pourquoi il y a de grands paliers suivis d’une baisse progressive, pourquoi ces paliers n’arrivent pas à des points réguliers, ni pourquoi des sauts plus importants ont parfois une pente plus faible.
Les autres graphiques évoluent encore selon des formes complètement différentes, ce qui les rend encore plus étranges.
Ils ne servent pas à montrer les vraies données ni leur signification, juste à faire passer l’idée que « quelque chose monte ».
Je pense que les federated forges représentent l’avenir.
Les dépôts devraient être hébergés chacun sur une infrastructure souveraine, avec au-dessus des identifiants globaux et des métadonnées fédérées pour les issues, les PR, etc.
Ce type d’index global est aussi facile à mettre en place, ce qui pourrait faire de la disponibilité un problème bien moins critique, et c’est dans cette direction que nous travaillons aussi.
Si l’on finit de toute façon par utiliser un hébergement tiers, on verra probablement réapparaître 1 à 3 gros acteurs.
Et même en auto-hébergement pour éviter les problèmes de disponibilité, si vos dépendances restent adossées à un gros service comme GitHub, vous ne pouvez toujours pas éviter les pannes de ce côté-là.
La solution réaliste reste donc, comme aujourd’hui, de tout proxifier ou de tout mirrorer.
Il suffit d’avoir le même repo sur GitHub, Codeberg et en self-hosted, puis de maintenir la cohérence de la branche principale.
Ensuite, on peut mettre à jour depuis n’importe lequel, à condition de bien placer les liens dans le README.
Si je pouvais brancher un autre forge offrant simplement une API ou des webhooks corrects et obtenir le même niveau de confort, je passerais tout en self-hosted.
Il faudrait aussi que les agents ouvrent leur interface de ce côté-là, mais avec une architecture par plugins, on pourrait sans doute retirer la dépendance à GitHub et gérer le reste avec MCP ou des skills.
Je n’ai pas de problème à auto-héberger les gros runners, donc j’ai récemment migré vers Codeberg, et pour les petites tâches cron j’utilise les runners fournis par Codeberg.
Ils ont même des lazy runners pour ce type d’usage.
Ce qu’ils font ressemble à ceci.
Les subventions en tokens ont déjà aspiré assez de données d’entraînement, et le business des adeptes de l’agentique est désormais assez gros pour faire tourner le flywheel, donc ils vont couper ça et nettoyer les produits d’appel à perte.
https://news.ycombinator.com/item?id=47923357