Composed

GitHub victime d'un incident mondial

GitHub détaille les causes de sa panne mondiale de 7 h 47, qui a perturbé l'authentification, l'API, Actions, Copilot et plusieurs services.

Publié le par Emmanuel LASTRAMis à jour le 2 min de lecture

Mise à jour du 21 août 2026 : GitHub a publié son analyse de la panne. L’incident a duré 7 h 47, entre 13 h 28 et 21 h 15 UTC. Il a commencé lorsqu’un nouveau pic de trafic a dépassé la capacité d’un composant d’infrastructure critique dans le centre de données Central US.

GitHub a subi ce lundi 17 août un incident majeur affectant plusieurs de ses services. La plateforme a signalé une dégradation touchant notamment l’interface web, l’authentification, l’API, les Pull Requests, les Issues, GitHub Actions, Copilot ainsi que les téléchargements d’archives et de contenu brut des dépôts. Selon GitHub, ces derniers ont enregistré un taux d’erreur d’environ 50 %, tandis que le trafic web et API a été affecté par un taux d’erreur d’environ 20 %.

Un défaut de mise à l’échelle à l’origine de la panne

La panne n’a été provoquée ni par un déploiement de code ni par un changement de configuration. Un pic de trafic a dépassé la capacité d’un composant qui ne se mettait pas correctement à l’échelle. Cette première défaillance a entraîné la saturation de plusieurs répartiteurs de charge, puis des erreurs d’authentification sur de nombreux services. Des mécanismes de nouvelles tentatives trop agressifs ont ensuite amplifié le trafic et retardé le rétablissement de Copilot.

La reprise a nécessité de rediriger une partie du trafic, d’isoler l’infrastructure touchée et de restaurer progressivement les services. La majorité d’entre eux fonctionnaient de nouveau à 16 h 36 UTC et GitHub Actions vers 18 h 03. Le service de jetons Copilot, dont le trafic avait été multiplié par environ dix, a été entièrement rétabli à 21 h 02.

GitHub annonce maintenant une correction des règles de mise à l’échelle, un audit des limites d’Istio, une révision des politiques de nouvelles tentatives et de temporisation ainsi qu’une amélioration de la surveillance des répartiteurs de charge et des mécanismes de bascule régionale. La société dit également avoir ajouté plus de trois millions de cœurs CPU et 120 pétaoctets de stockage rapide. Selon GitHub, Azure prend désormais en charge environ 58 % de la charge de la plateforme et la moitié des opérations Git, contre 12 % de la charge en mai.

Le bilan publié par GitHub présente les travaux engagés pour améliorer la fiabilité de la plateforme. La chronologie technique de l’incident détaille la saturation, les effets en cascade et les différentes étapes du rétablissement.

Tags