Incident affectant Issues et Webhooks – résolu

 (githubstatus.com)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • GitHub a enquêté sur une dégradation des performances de Issues et des Webhooks, puis a fait passer l’incident à l’état résolu le 4 mai 2026 à 16:40 UTC
  • Cet incident a affecté Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages et Codespaces
  • À 15:45 UTC, l’enquête a commencé sur une dégradation des performances de Issues et Webhooks, puis à 15:48 UTC elle a été élargie à une enquête sur une augmentation de la latence et des timeouts touchant plusieurs services GitHub
  • À partir de 16:25 UTC, Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces et Webhooks ont été rétablis ou atténués successivement
  • GitHub a indiqué que la latence sur l’ensemble des services était revenue à la normale et qu’une analyse des causes racines ainsi que des mesures de prévention de récurrence étaient toujours en cours et seraient partagées dès qu’elles seraient prêtes

Aperçu de l’incident

  • GitHub a annoncé que l’incident était résolu après avoir enquêté sur des signalements de dégradation des performances de Issues et des Webhooks
  • L’incident a affecté Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces
  • GitHub a remercié les utilisateurs pour leur patience pendant le traitement du problème et a indiqué qu’une analyse détaillée des causes racines serait partagée dès qu’elle serait prête

Déroulement

  • Début de l’enquête

    • Le 4 mai 2026 à 15:45 UTC, GitHub a annoncé enquêter sur des signalements de dégradation des performances de Issues et des Webhooks
    • À 15:48 UTC, l’annonce a été élargie à une enquête sur une augmentation de la latence et des timeouts dans plusieurs services GitHub

  • Extension des services affectés

    • À 15:48 UTC, GitHub a annoncé que Git Operations subissait une dégradation des performances
    • À 15:50 UTC, GitHub a annoncé que Packages subissait une dégradation des performances
    • À 15:51 UTC, GitHub a annoncé que Actions subissait une dégradation des performances
    • À 15:51 UTC, GitHub a annoncé que Pull Requests subissait une baisse de disponibilité
    • À 15:56 UTC, GitHub a annoncé que Pull Requests subissait une dégradation des performances
    • À 16:05 UTC, GitHub a annoncé que Codespaces subissait une dégradation des performances
    • À 16:06 UTC, GitHub a annoncé que Pages subissait une dégradation des performances

  • Retour à la normale et atténuation

    • À 16:25 UTC, GitHub a annoncé que Git Operations fonctionnait de nouveau normalement
    • À 16:28 UTC, GitHub a annoncé que Actions et Packages fonctionnaient de nouveau normalement
    • À 16:29 UTC, GitHub a annoncé que Pages fonctionnait de nouveau normalement
    • À 16:29 UTC, GitHub a annoncé que la latence sur l’ensemble des services était revenue à la normale et que l’enquête sur la cause racine ainsi que les mesures de prévention de récurrence se poursuivaient
    • À 16:32 UTC, GitHub a annoncé que Pull Requests fonctionnait de nouveau normalement
    • À 16:34 UTC, GitHub a annoncé que la dégradation des performances ayant affecté Issues était atténuée et qu’une surveillance était en cours pour confirmer la stabilité
    • À 16:35 UTC, GitHub a annoncé que la dégradation des performances ayant affecté Codespaces était atténuée et qu’une surveillance était en cours pour confirmer la stabilité
    • À 16:35 UTC, GitHub a annoncé que Webhooks fonctionnait de nouveau normalement

  • Résolution

    • À 16:36 UTC, GitHub a annoncé que la dégradation des performances était atténuée et qu’une surveillance était en cours pour confirmer la stabilité
    • À 16:40 UTC, l’incident est passé à l’état résolu
    • Une analyse détaillée des causes racines sera partagée dès qu’elle pourra être fournie

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Commentaires de Hacker News

  • GitHub a publié des chiffres surprenants sur la hausse d’utilisation en l’attribuant à l’augmentation du codage agentique ; au bout d’un moment, ils devront sans doute soit modifier les limites de débit, soit réduire l’usage du forfait gratuit, soit trouver un autre moyen de diminuer la charge
    Il semble clair que l’infrastructure ne suit pas cette croissance, et il est peu probable que GitHub absorbe indéfiniment ce surcoût. Je me demande comment GitHub va évoluer à partir de là

    • Le 3 avril, la COO de GitHub avait déjà indiqué que l’activité sur la plateforme explosait
      En 2025, il y avait 1 milliard de commits, et maintenant on est à 275 millions par semaine ; même avec une simple croissance linéaire, cela mettrait l’année sur un rythme de 14 milliards. GitHub Actions est aussi passé de 500 millions de minutes par semaine en 2023 à 1 milliard de minutes par semaine en 2025, et a déjà atteint 2,1 milliards cette semaine
      Ils disent pousser très fortement sur l’ajout de CPU, l’extension des services et le renforcement des fonctionnalités cœur de GitHub
      https://x.com/kdaigle/status/2040164759836778878
      Il y a aussi un billet de blog récent sur la disponibilité : https://github.blog/news-insights/company-news/an-update-on-...
      Les problèmes de passage à l’échelle auxquels les ingénieurs de GitHub sont confrontés ont l’air vraiment corsés
    • Quand on observe ça depuis des décennies, il y a d’un côté les systèmes qui rendent chaque opération peu coûteuse et de l’autre ceux qui misent à fond sur la montée en charge horizontale ; très souvent, les premiers l’emportent largement sur les seconds
      Par exemple, GitHub semble avoir implémenté la page /pulls d’un dépôt comme une requête de recherche ; le champ de recherche prérempli en donnait l’indice, et la panne du backend de recherche la semaine dernière l’a quasiment confirmé quand les pull requests ne chargeaient plus. Pourtant, on aurait aussi pu l’implémenter avec un simple appel d’API qui ne récupère que les pull requests ouvertes ; cette API existe, et elle n’était pas en panne
      Si GitHub se concentrait sur l’identification puis l’optimisation des 95 % d’opérations les plus courantes, comme le chargement de page et les appels d’API associés, la seule simplification pourrait probablement réduire la charge backend de plus de 5x
      Le visualiseur de diff semble lui aussi avoir une large marge d’amélioration. Une bonne part de cette horrible inefficacité vient probablement du frontend plutôt que de charges directes sur le backend, mais les fonctions ordinaires en ligne de commande git restent très rapides
    • On dirait qu’on approche maintenant du point de non-retour. À moins de séparer l’infrastructure gratuite et payante, je ne sais pas s’ils pourront sortir du trou qu’ils ont eux-mêmes creusé uniquement par montée en charge horizontale
      De la même façon qu’il faut être 10 fois meilleur pour pousser quelqu’un à changer de produit, si le produit en place devient 10 fois pire, les concurrents gagnent automatiquement un avantage x10 sans rien faire
    • Une semaine après que GitHub a publié ça sur son blog, puis un jour après que des dirigeants de GitHub l’ont répété dans les commentaires HN, l’idée que la baisse de fiabilité continue depuis 2019 ne serait pas due à l’intégration à Microsoft en 2019 mais à quelque chose apparu seulement en 2023 est soudain devenue une évidence partagée
      La RP fonctionne. On en est arrivé à la conclusion que si GitHub ne marche pas, c’est parce qu’il a trop de succès
    • Je soutiens fermement la réaffectation de toute la capacité serveur de LinkedIn à GitHub

  • D’après https://mrshu.github.io/github-statuses, la disponibilité sur les 90 derniers jours de GitHub est de 84,92 %
    Je ne vois pas comment cela pourrait être considéré comme un niveau ne serait-ce qu’un peu acceptable

    • Ce site semble surestimer le temps d’indisponibilité. Même en filtrant uniquement les incidents major et critical dignes de la une de HN, ça reste mauvais, mais pas au point de 84,92 %
      https://isgithubcooked.com/?severities=major.critical
    • Ce n’est pas acceptable. Beaucoup de choses inacceptables se produisent en ce moment, et pourtant tout le monde semble les accepter comme si de rien n’était
    • On n’atteint même pas le niveau des deux huit, alors ne parlons même pas des three nines

  • Les performances sont désormais tombées à un niveau difficilement acceptable. Il ne se passe pas une semaine sans que mon travail soit interrompu à cause de GitHub

    • Les agents IA ont en pratique modifié les caractéristiques de passage à l’échelle de tout l’internet
      Avant, GitHub pouvait supposer qu’un nombre limité d’humains utilisait la plateforme d’une manière humaine et avec des schémas observables, puis dimensionner ses systèmes et optimiser ses goulets d’étranglement UI/UX en fonction de ces schémas
      Mais maintenant, tout le monde a un bot qui tourne 24 h/24, parfois plusieurs, et cela surcharge de nombreux services, en particulier ceux qui sont désormais aussi centrés sur les agents que GitHub
    • C’était déjà inacceptable depuis des mois, et on est maintenant proche du moment où il faut chercher activement des alternatives
    • On en est au point où il faudrait se réjouir quand une seule journée passe sans incident, pas une semaine
      Le nombre de lundis matins, heure du Pacifique, où ça se répète m’échappe complètement désormais
    • En Europe, c’est nettement mieux. J’avais fini ma journée quelques heures avant le début de cette panne, et je me souviens mal de grosses interruptions ayant réellement stoppé mon travail ces derniers mois
      Il m’est quand même arrivé une fois récemment d’être affecté le soir en travaillant sur un projet perso
    • À mon avis, on a dépassé depuis très longtemps le stade de l’inacceptable

  • À ce stade, un post GitHub est down sur la une de HN rivalise chaque semaine avec un nouveau post d’exagération sur les LLM
    J’envisage de déplacer tous mes projets personnels sur Codeberg. La fiabilité de GitHub est une raison, mais j’apprécie aussi le fait que ce soit une alternative qui ne soit pas étroitement liée à une grande entreprise tech

    • Le spam du genre Claude Code est presque magique était le pire, mais il semble avoir été temporairement repoussé par les posts sur l’état de GitHub. C’est peut-être juste une période plus calme pour la pub autour de Claude
    • Et pourtant, le fait que les gens n’aient toujours pas migré montre bien le problème des plateformes dominantes. Un peu d’inertie et quelques désagréments suffisent à empêcher presque tout le monde de partir
      Même sans abus monopolistique, et ici je parle bien de Microsoft

  • Ce qui est drôle, c’est qu’à part Copilot, presque tout semble être en dégradation de performance. Les blagues s’écrivent toutes seules

    • Comparé aux fonctionnalités actuellement dégradées, l’ensemble des fonctions de Copilot ne représente qu’une utilité partielle
    • Copilot est probablement complètement indépendant du côté dépôt de code de GitHub, et tourne sur une infrastructure totalement différente, sans forte dépendance au monolithe Rails

  • C’est étrange et un peu triste, mais j’ai l’impression de commencer à développer un sixième sens pour détecter les pannes GitHub
    Il y a environ une heure, j’ai cliqué sur « Resolve Conversation » dans une pull request et ça a échoué plusieurs fois ; le message d’erreur apparaissait hors écran en bas de page, donc je ne l’ai pas vu tout de suite. Je devais rafraîchir la page toutes les quelques actions pour que le serveur prenne en compte le nouvel état
    J’ai dit à un collègue que GitHub semblait avoir un problème dans un autre service qui se propageait aux commentaires de PR, et que ça pouvait finir par dégénérer en panne plus large

    • Je viens de voir exactement le même signal dans des commentaires de revue de PR. J’ai vérifié la page de statut, elle était verte, et je me suis dit que ça n’allait pas durer ; j’avais raison

  • Il faut réduire le forfait gratuit
    J’ai fait 4 000 commits sur les 2,5 derniers mois, rien que sur main. Je pousse aussi tous les jours plein d’artefacts pour les tests de régression
    Coût : 0 dollar

    • Honnêtement, je déteste les forfaits gratuits de ce genre de produits SaaS
      À l’époque où Google proposait très brièvement un service Git facturé à l’usage sur GCP, j’utilisais ça. Je voulais posséder ce qui était à moi. Mais tout le monde utilisait GitHub « gratuit », et comme beaucoup d’autres services Google, celui-là semble avoir été abandonné
      Donc maintenant j’utilise GitHub gratuitement, mais je préférerais payer un grand fournisseur cloud pour le stockage des dépôts et l’usage
    • Si c’est le cas, les projets open source qui ne sont pas encore partis migreront
    • Rien que côté dépôt, ça représente probablement l’équivalent de deux minutes d’utilisation CPU
    • GitHub devrait instaurer une taxe sur le code poubelle. Coécrit avec Claude ? Tu payes. Trop de tirets cadratins dans les commentaires ? Tu payes. Beaucoup de code écrit en peu de temps ? Tu payes

  • On atteint un niveau vraiment ridicule. La page de statut inclut parfois Copilot dans ce qui est « dégradé », mais il faut regarder le fait que la disponibilité des pull requests est de 95,5 %, donc inférieure aux 96,4 % de Copilot
    Je ne vois pas comment on est censé laisser un commentaire « LGTM » si on n’arrive même pas à accéder à la PR

  • Au moins, les gens apprennent à utiliser la commande git remote