Plusieurs incidents affectant des services GitHub

• Une dégradation de disponibilité et des indisponibilités ont touché plusieurs services GitHub, dont Webhooks, Actions et Copilot
• Au départ, l’enquête portait sur une dégradation de disponibilité de Copilot et Webhooks, puis son périmètre a été élargi à plusieurs pannes de service
• Actions a subi séparément une baisse de performances, et des mesures d’atténuation ont été engagées après l’identification du problème racine
• Après l’atténuation des dégradations touchant Actions et Copilot, la surveillance de la stabilité et les travaux de vérification sur les services restants se sont poursuivis, et Webhooks a lui aussi retrouvé un fonctionnement normal
• Cet incident a finalement été entièrement résolu, et une analyse détaillée de la cause racine sera partagée dès qu’elle sera prête

---

Déroulement de l’incident

• Plusieurs services GitHub ont été touchés par une panne, notamment Webhooks, Actions et Copilot
• Au départ, GitHub a commencé à enquêter sur une dégradation de disponibilité de Copilot et Webhooks
• Par la suite, plusieurs services sont passés en indisponibilité, ce qui a élargi le périmètre de l’enquête
• Actions a subi séparément une baisse de performances, et l’identification de la cause s’est poursuivie
• Une fois le problème racine confirmé, des mesures d’atténuation ont été mises en œuvre
• Les dégradations affectant Actions et Copilot ont été atténuées, et la surveillance s’est poursuivie pour maintenir la stabilité
• Après l’atténuation sur de nombreux services, des travaux de vérification ont également continué sur les services restants
• Webhooks a lui aussi retrouvé un fonctionnement normal
• Finalement, cet incident a été marqué comme entièrement résolu, et une analyse détaillée de la cause racine sera partagée dès qu’elle sera prête

Liens de référence

• Page principale GitHub Status
• État actuel
• Site d’assistance

[GN⁺]

Avis sur Hacker News

• J’étais en train de migrer diverses choses chez moi en self-hosting, et hier j’ai enfin terminé une instance Forgejo à la maison
  Linux et Windows tournent en VM, macOS sur un Mac Mini, avec même des runners CI/CD branchés dessus, donc désormais tout le code source, les Actions et l’infrastructure réelle sont littéralement chez moi
  En général, il faut un ou deux mois après être passé au self-hosting pour ressentir la satisfaction, mais cette fois, dès le lendemain de la fin de la migration, j’étais déjà convaincu d’avoir fait le bon choix, ce qui était assez agréable

  • L’idée d’un homelab m’attire toujours, mais dès que je commence à en monter un, je me fatigue vite
    Après avoir passé toute la journée au travail à réparer des systèmes cassés, je n’ai pas envie de rentrer chez moi pour assumer en plus le rôle de sysadmin perso
    J’ai bien un Minisforum correct et performant acheté à Noël sur le bureau, mais je ne l’ai toujours même pas allumé
  • Dès qu’on se met au self-hosting, on réalise immédiatement à quel point le web moderne est lent
    Je fais tourner Forgejo sur un NUC avec plusieurs autres services sur Proxmox, et les pages se chargent en 6 ms environ
    Immich n’est pas aussi rapide, mais reste quand même bien plus véloce que Google Photos
  • J’exploite depuis un moment un Forgejo personnel, sur lequel j’héberge tous mes side projects privés
    L’interface est globalement similaire, mais c’est bien plus agréable que GitHub. Rien que le fait d’avoir plus de 90 % d’uptime suffit presque comme explication
    Ces temps-ci, j’ai des problèmes avec GitHub bien trop souvent, et même simplement parcourir le site est souvent lent, voire complètement bloqué
  • J’ai fait la même migration récemment, et ce qui m’a le plus surpris, c’est que la vitesse des Actions est bien meilleure que sur GitHub
    J’ai configuré Linux et macOS avec un Mac Mini et un fichier de tâches Ansible généré par Claude, mais la configuration de la VM Windows avait l’air franchement pénible
    Je me demande si tu as trouvé un moyen de simplifier le déploiement
  • Hier, après avoir vu passer ici une discussion sur gitea, j’ai creusé un peu puis je suis moi aussi passé en self-hosting et j’ai migré tous mes projets persos vers Forgejo
    En revanche, les projets publics sont difficiles à déplacer à cause du marché de l’emploi et de l’effet de réseau de GitHub
    Pour l’instant, j’ai l’impression de jouer à l’administrateur système en faisant tourner une vingtaine de services locaux pour tout ce dont j’ai besoin, et le plus important désormais, c’est que la responsabilité d’éviter toute perte de données m’incombe, donc il faut absolument mettre en place des sauvegardes régulières

• En regardant https://mrshu.github.io/github-statuses/, l’uptime est descendu à 88,15 %
  Même par composant individuel, le maximum n’est que de 99,78 %, donc on est à peine au niveau de two nines

  • L’échelle de croissance à gérer est franchement absurde
    En 2025, c’était 1 milliard de commits, et maintenant c’est 275 millions de commits par semaine ; même en supposant une croissance linéaire, ils sont sur un rythme de 14 milliards de commits cette année
    GitHub Actions est aussi passé de 500 millions de minutes par semaine en 2023 à 1 milliard de minutes en 2025, et cette semaine on en est déjà à 2,1 milliards de minutes
    La source est un post du COO de GitHub daté du 2026-04-03 : https://x.com/kdaigle/status/2040164759836778878
  • Je me demande s’il existe une corrélation avec le fait que GitHub ait commencé à prioriser la migration vers Azure
    https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/
  • L’IA poussée par Microsoft est au final d’une grande aide pour les adeptes du self-hosting et de Linux

• Je me demande si, malgré la répétition de ces incidents, GitHub subit réellement une perte commerciale significative
  Dans le secteur, on a longtemps dit que la fiabilité et la valeur de marque étaient essentielles, mais ces temps-ci on a l’impression que plus personne ne s’en soucie vraiment
  Si ma perception est erronée, je veux bien qu’on me corrige

  • Il y a à peine 2 ou 3 ans, presque tout le monde s’accordait à dire que pour déployer du logiciel de manière stable et sûre, il fallait des repeatable builds, une chain of custody vérifiée et une bill of materials auditables
    Et puis les LLM se sont un peu améliorés, et on a l’impression que toute cette discussion a tout simplement disparu
  • GitHub est déjà une plateforme trop ancrée pour que ce genre de panne soit autre chose qu’un simple coût d’exploitation
    Les grandes entreprises se protègent dans une certaine mesure avec des instances internes, et pour les autres, soit ce n’est pas assez critique, soit elles n’ont pas les ressources pour construire leur propre solution ou migrer ailleurs
  • Passer de GitHub à GitLab pourrait revenir à sortir de la poêle pour tomber dans le feu
    J’aimerais qu’il existe une alternative vraiment valable pour ceux qui en ont besoin à grande échelle

• Sur une fenêtre glissante de 90 jours, il faudrait probablement encore environ 16 heures d’incident supplémentaire pour tomber sous les two nines

  • En regardant https://mrshu.github.io/github-statuses/, l’uptime agrégé n’atteint même pas 1 nine
  • À ce rythme, GitHub vise les huit 8

• Je suppose qu’il n’y a pas lieu de s’inquiéter, puisque la status page dit toujours tout vert, 100 % opérationnel
  Et ce alors qu’on n’arrive même pas à accéder à une simple page statique

• On en est au point où il devrait y avoir un post HN chaque fois qu’il n’y a pas de problème sur les services GitHub
  Ou alors cela signifie simplement que c’est devenu l’état normal

• Il y a quelque temps, du côté de Bitbucket, ils ont perdu une journée d’historique git sur plusieurs repo
  Ce n’était pas vraiment une panne mais plutôt un problème de données chez eux ; on a pu sauver l’essentiel grâce aux clones locaux, mais les issues et PR de ce créneau ont simplement disparu
  C’est ce qui m’a poussé à commencer gitbacker comme side project
  Sauvegarder les repo eux-mêmes est facile ; la partie vraiment intéressante, c’est la sauvegarde des metadata

• Il y a encore eu aujourd’hui un incident très grave : https://www.githubstatus.com/incidents/zsg1lk7w13cf
  À cause d’une régression lorsqu’on utilisait merge queue avec squash merge ou rebase, certains PR ont été fusionnés incorrectement entre 2026-04-23 16:05 et 20:43 UTC
  Chez nous, pendant ce créneau, environ 8 commits ont été entièrement annulés sur la branche par défaut
  Je n’avais encore jamais vu un incident GitHub aussi grave

  • Le downtime est un problème, mais annuler discrètement des commits sur la branche par défaut, c’est une tout autre catégorie d’échec
  • On a eu quelque chose de similaire nous aussi
    C’est ironique qu’un outil censé éviter les merge conflicts ait au contraire écrit directement des commits corrompus sur la branche principale
  • Chez nous aussi, plusieurs commits ont disparu de main alors que l’état des PR restait sur merged
    C’était vraiment très stressant
  • Chez nous aussi, des PR ont été annulées dans plusieurs repo
    Le downtime est déjà un problème, mais annuler des PR, c’est encore un cran au-dessus en gravité
  • Nous aussi, on a reçu un e-mail avec un PDF en pièce jointe listant les commits affectés et la marche à suivre pour restaurer
    C’était un chaos total

• De notre côté, les besoins sont plutôt simples, du genre git repos + actions, et les pannes occasionnelles ne sont pas totalement critiques puisque nous ne sommes pas une équipe qui commit et déploie en continu
  Malgré tout, nous cherchons désormais sérieusement une alternative
  Apparemment, d’autres faisaient la même chose, car SourceHut est aussi tombé. Il était hors ligne au moment où j’écris, puis il est revenu
  https://sr.ht/

  • Je me demande ce que vaut tangled.org

• Rien qu’aujourd’hui, il y a eu trois incidents, chacun durant presque plus d’une heure, mais l’état journalier reste entièrement vert et affiche aucun downtime enregistré
  Cela ne semble pas fondamentalement différent des incidents d’avant qui s’affichaient avec des barres rouges, à part le fait qu’ils n’ont pas duré plusieurs heures
  Du coup, je ne comprends plus du tout ce que signifient ces barres vertes
  Je me demande s’il faut que les gens se plaignent suffisamment pour qu’elles passent ensuite en non-vert, ou si les incidents du jour n’apparaissent que temporairement dans l’infobulle avant d’être discrètement oubliés plus tard
  Quand on voit que jusqu’ici les dates vertes n’affichent aucun incident dans l’infobulle, alors qu’aujourd’hui on en voit plusieurs, dans un cas comme dans l’autre cela donne l’impression d’un affichage volontairement trompeur