GitHub subit une nouvelle panne

• Une dégradation des performances de certains services GitHub a été signalée, avec des retards dans la livraison des notifications
• Le délai moyen est d’abord passé à environ 50 minutes, puis a atteint jusqu’à 1 heure et 20 minutes
• Une reprise progressive a ensuite eu lieu, réduisant le retard de 1 heure → 30 minutes → 15 minutes
• Le problème a été déclaré résolu et l’incident clos le 9 février 2026 à 19:29 UTC
• GitHub prévoit de publier ultérieurement une analyse des causes profondes (RCA)

---

Aperçu de l’incident de retard des notifications GitHub

• GitHub a signalé une dégradation des performances sur certains services
  • Lors de la phase initiale, l’envoi des notifications ne s’effectuait pas normalement
  • L’enquête sur la cause du problème était en cours

Évolution du retard des notifications

• La première mise à jour précisait un retard moyen de 50 minutes
  • GitHub a indiqué être en train de déployer des mesures d’atténuation
• Une mise à jour ultérieure a signalé une aggravation à 1 heure et 20 minutes de retard, tout en observant des signes de reprise
• La restauration a progressé graduellement, ramenant le délai de 1 heure → 30 minutes → 15 minutes
  • GitHub a expliqué être en train de traiter le backlog (notifications accumulées)
• Finalement, le problème de retard des notifications a été résolu et l’envoi normal a repris

Clôture de l’incident et mesures de suivi

• L’incident a été entièrement résolu le 9 février 2026 à 19:29 UTC
• GitHub a remercié les utilisateurs pour leur patience et leur compréhension
• Les résultats de l’analyse des causes profondes (Root Cause Analysis) seront publiés dès qu’ils seront prêts

Notifications utilisateur et fonctions d’abonnement

• Les utilisateurs peuvent s’abonner aux mises à jour de l’incident par e-mail, SMS, Slack, Webhook, etc.
• En s’abonnant, ils acceptent la politique de confidentialité et les conditions d’utilisation de GitHub et Atlassian
• Le site est protégé par Google reCAPTCHA

Résumé

• Cet incident concernait un problème de retard du système de notifications de GitHub, avec une restauration progressive sur environ 4 heures
• Le service est désormais revenu à la normale et un rapport d’analyse complémentaire est prévu

[joyfui]

Apparemment, je n’étais pas le seul à voir GitHub cracher des erreurs à l’aube aujourd’hui.

[GN⁺]

Avis sur Hacker News

• GitHub ne publie plus ses statistiques de disponibilité du service, donc j’ai parsé les données moi-même
  À l’heure actuelle, l’ensemble du service semble être au niveau d’un « single 9 »
  C’est visible sur la page GitHub Statuses

  • Ça me rappelle l’ancienne page d’état de GitHub. À l’époque, elle montrait de façon transparente le véritable temps de disponibilité, donc ce n’est pas surprenant qu’elle ait été remplacée par la page actuelle dès que la vérité est apparue
    J’ai aussi bien lu l’explication du lien archive.org
  • Dire que l’ensemble du service est à « single 9 » n’a pas de sens du point de vue du mode de calcul de la disponibilité
    Les chiffres par domaine sont utiles, mais tout fusionner en un seul indicateur ne veut rien dire
    La plupart sont au-dessus de 99,5 %, sauf Copilot apparemment
  • Il est intéressant que le chiffre global de Copilot soit le plus bas
    Je l’utilise tous les jours, mais j’ai rarement remarqué de problème. J’imagine que le moment d’enregistrement des incidents est reporté tardivement
  • Je ne comprends pas pourquoi la panne d’aujourd’hui a été classée comme « minor »
    L’interface web ne fonctionnait pratiquement pas, donc je me demande si GitHub ne minimise pas la gravité des incidents
  • Beau projet. Merci de l’avoir partagé

• Il y a encore quelques années, je n’aurais jamais pensé que la position dominante de GitHub pourrait être menacée
  Mais si l’exploitation reste aussi instable, cela risque d’entrer dans l’histoire comme un but contre son camp emblématique du secteur

  • Depuis la migration « existentielle » vers Azure l’an dernier, la disponibilité semble avoir chuté d’un ou deux crans
  • Je regarde en ce moment la page « Migrate from GitHub » de la documentation GitLab
    Si je peux aussi récupérer les issues et les projets, j’envisage sérieusement de migrer
  • À mon avis, ce n’est pas seulement un problème d’exploitation, mais aussi un problème d’architecture et de qualité du code
    Il suffit de voir le produit GitHub Enterprise self-hosted pour comprendre à quel point c’est complexe
  • Je n’ai aucune preuve, mais je soupçonne que la multiplication récente des pannes pourrait être un effet secondaire de la stratégie centrée sur l’IA
  • Je pense que c’est le résultat d’une migration forcée par Microsoft vers Azure avec priorité donnée aux charges de travail IA
    GitHub est la poule aux œufs d’or des données de développement mondiales, et si ça reste aussi instable, c’est toute la franchise qui est en danger
    Windows 11 n’est déjà pas fameux, et GitHub pourrait perdre son rôle de socle du développement moderne

• J’étais en train de traiter un bug de sécurité dans Caddy quand GitHub est tombé, et en ouvrant le rapport je ne voyais que la page licorne
  J’essayais de profiter de deux heures sans les enfants pour me concentrer, et je crains que cette panne ne repousse la boucle de retour jusqu’à demain
  Malgré tout, je reste reconnaissant, car GitHub Sponsors me permet de gagner ma vie

  • Je suis curieux de savoir de quel bug de sécurité il s’agit
  • J’aimerais aussi demander si tu as déjà envisagé une plateforme alternative. Comme j’administre mon propre serveur, la sécurité est importante pour moi

• On peut voir GitHub se fragmenter et exploser en temps réel
  La page GitHub Status History en devient presque comique

  • Nous sommes le 9 février et il y a déjà eu 14 incidents
    C’est ironique de voir encore une fois la phase du « sauveur » de l’industrie de l’IA tourner comme ça
    Article lié : lien The Verge
  • Pour inverser cette tendance, il faudrait faire encore plus de vibe coding, plaisante quelqu’un
  • Malgré tout, c’est bien que GitHub publie ça de manière transparente
    Comme ils ne cachent pas les pannes, on peut réagir, et il y aura sans doute bientôt un retour d’expérience
  • Ça va probablement continuer jusqu’à la fin de la migration vers Azure
  • J’aimerais bien une visualisation annuelle comme le graphe de contributions des profils GitHub

• Depuis le début de l’année, GitHub a eu tellement d’incidents qu’ils mettent presque à jour la page d’état tous les jours
  Quand on regarde l’historique d’état, ce n’est pas normal, même pour un grand service
  Il y a même une blague disant que GitHub Actions s’arrête tous les jours vers 16 h
  J’aimerais qu’ils publient en interne les causes et les mesures correctives

  • Depuis l’arrivée des agents de code, le trafic opérationnel a peut-être été multiplié par 100
    GitHub avait été conçu pour une toute autre échelle, et s’est retrouvé d’un coup confronté à une charge d’un nouvel ordre de grandeur

• Au départ, la page d’état n’indiquait qu’un retard dans les notifications, mais en réalité, la page licorne apparaissait sans arrêt lors de l’accès aux PR
  Ensuite, une page d’état distincte liée aux PR est apparue, puis le problème a finalement été étendu à l’ensemble du service
  Lien vers l’incident concerné

  • Une ligne « enquête sur une dégradation des performances de certains services » a été ajoutée
    Elle n’était pas là à 16:10 UTC, puis elle est apparue quelques minutes plus tard
  • Lors de l’approbation d’une PR, l’API JSON renvoie une page d’erreur HTML. On dirait que l’intérieur est complètement embrouillé
  • Moi aussi je vois souvent des erreurs 500. La latence a aussi fortement augmenté
    Lien de monitoring
  • En accédant aux détails d’un commit, je n’obtiens moi aussi que la page licorne
  • Même les commandes git elles-mêmes ne fonctionnent pas

• J’ai terminé ces dernières semaines une migration vers Forgejo
  Dans notre entreprise, nous cherchions à réduire notre dépendance aux grands clouds, donc il était absurde que notre infrastructure critique puisse s’arrêter à cause d’une panne GitHub/Azure
  La transition s’est bien passée, et nous sommes aussi en train de faire quelques développements sur mesure

  1. Nous avons créé un runner basé sur Firecracker pour exécuter la CI de Forgejo Actions dans un environnement VM
  2. Nous préparons une proposition pour ajouter une fonction de groupes de variables d’environnement
     La communauté est très accueillante, et j’espère que Forgejo continuera à grandir
     Lien de l’entreprise, lien vers la discussion de la proposition
  • Si vous êtes à Londres, pourquoi utiliser un domaine en .eu ? Je suis aussi curieux de connaître l’emplacement des serveurs et le fournisseur d’hébergement

• L’instabilité de GitHub est désormais inacceptable
  Si je peux influencer à l’avenir le choix d’un dépôt de code, je ferai en sorte d’éviter GitHub

  • Les fonctionnalités peuvent largement être remplacées par d’autres forges (Forge)
    En revanche, la découvrabilité de GitHub et les signaux sociaux (étoiles, forks) restent encore attractifs
    Une approche réaliste consiste à utiliser une forge interne (GitLab, Gitea, etc.) et à ne faire qu’un miroir sur GitHub
    Ironiquement, si GitHub avait été meilleur, j’aurais pris une offre payante, alors qu’aujourd’hui je n’utilise que la version gratuite et je dépense mon argent ailleurs

• Il y a eu trois pannes majeures au cours des trois derniers mois
  C’est également indiqué dans l’historique d’état

  • Je me demande qui est parti récemment de l’équipe. Peut-être qu’un détenteur de connaissances clés est parti, ou que l’exploitation a été déplacée dans une autre région
  • Nous devons lancer notre MVP dans deux semaines, et encore une panne… c’est frustrant. La fiabilité est bien trop faible
  • Quelqu’un ajoute en plaisantant que c’est peut-être encore à cause du vibe coding

• La situation actuelle donne vraiment l’impression que l’IA a remplacé les ingénieurs

  • « Oui, désolé. J’ai supprimé ta base de données. », répond quelqu’un en plaisantant
  • En réalité, je crois savoir que ces interruptions viennent du fait que GitHub est en train de migrer vers Microsoft Azure
  • C’est comme si Tay.ai et Zoe.ai se battaient en interne au point de ne plus pouvoir maintenir le service, dit-on sur le ton de la satire