Panne GitHub de 8h aggravée par ses propres retries

GitHub est resté inaccessible près de 8 heures le 17 août

GitHub.com a subi une panne de 7 heures et 47 minutes le 17 août 2026, de 13h28 à 21h15 UTC, qui a dégradé presque tous les flux de travail centraux des développeurs sur la plateforme. Des erreurs et des latences élevées ont touché en même temps Issues, Pull Requests, les API REST et GraphQL, GitHub Actions et GitHub Copilot, si bien que la perturbation ne s'est pas limitée à une seule fonctionnalité. Le post-mortem de GitHub, publié sur github.blog sous le titre "The August 17 outage and the work ahead", situe le taux d'erreurs maximal autour de 20% sur tout le site, et autour de 50% spécifiquement pour les téléchargements d'archives et de fichiers bruts. The Register, TechTimes et dev.to ont corroboré la chronologie et l'ampleur dans leur propre couverture de l'incident.

La cause est un proxy à sa limite, pas un déploiement défaillant

Le post-mortem de GitHub affirme clairement que la panne n'a pas été causée par un déploiement de code ou de configuration ; il s'agit d'une défaillance de capacité et de supervision au sein même de l'infrastructure réseau de l'entreprise. L'élément déclencheur a été un proxy sidecar de service mesh Istio dans un centre de données de Central US, qui a atteint sa limite de concurrence lorsque le trafic est arrivé selon un nouveau pic pour lequel le système n'était pas dimensionné. Un sidecar de service mesh se place à côté de chaque instance de service pour gérer son trafic réseau, si bien que lorsqu'il atteint un plafond strict sous une charge inattendue, tout ce qui transite par lui échoue d'un coup au lieu de se dégrader progressivement.

Une alerte mal configurée a fait que personne ne l'a vu venir

Une politique de supervision interne était mal configurée et n'a pas alerté les ingénieurs de GitHub lorsque le proxy sidecar approchait de sa limite de concurrence, si bien que l'alerte censée déclencher une réponse avant que les utilisateurs ne remarquent quoi que ce soit ne s'est tout simplement jamais déclenchée. Cette lacune compte autant que la limite de concurrence elle-même : une limite de capacité repérée tôt est une mise à niveau discrète, une limite repérée seulement après que les utilisateurs voient des erreurs devient un incident de plusieurs heures. GitHub indique que combler cette lacune de supervision fait partie du "work ahead" mentionné dans le titre de son post-mortem.

Les propres retries de GitHub, surtout depuis VS Code, ont aggravé la panne

La logique optimiste de nouvelles tentatives côté client dans tout l'écosystème GitHub a transformé un proxy surchargé en une cascade touchant toute la plateforme, et GitHub a désigné une tempête de retries provenant des clients VS Code comme un facteur majeur de la gravité de la panne. Quand une requête échoue et qu'un client la retente aussitôt sans attendre, elle n'échoue pas simplement une nouvelle fois, elle ajoute une requête supplémentaire à un système déjà surchargé, et multiplié par des millions d'installations de VS Code interrogeant GitHub en arrière-plan, ce schéma a transformé un problème de proxy contenu en un problème touchant toute la plateforme. C'est ce détail qui transforme l'incident, d'une histoire sur l'infrastructure de GitHub, en une histoire sur la façon dont devrait être conçu tout client de toute API.

Pour toute entreprise dont le pipeline passe par GitHub, ce fut un black-out de 8 heures

La plupart des entreprises voient une panne de GitHub comme un désagrément pour les développeurs, quelque chose dont on se plaint en attendant, mais pour toute entreprise ayant discrètement intégré GitHub Actions et Copilot à son pipeline de déploiement, 7 heures et 47 minutes sans GitHub, ce sont 7 heures et 47 minutes pendant lesquelles on ne peut ni livrer de correctif d'urgence, ni fusionner un correctif de sécurité, et, si Copilot fait partie du flux de travail, on perd un outil de codage assisté par IA en pleine tâche. C'est un risque de concentration sur un seul fournisseur, caché derrière ce qui ressemble à "simplement utiliser GitHub", et cela n'apparaît sur aucune ligne budgétaire comme le ferait un abonnement logiciel. La leçon la plus tranchante est la tempête de retries : si le logiciel client de GitHub lui-même a aggravé une panne en retentant de façon agressive sans attendre, toute entreprise qui construit ses propres systèmes contre des API tierces devrait vérifier sa propre logique de nouvelles tentatives pour le même défaut, plutôt que de le classer comme un problème purement lié à GitHub.

À lire ensuite: L'Agent IA de Wiz a Piraté Snowflake, Puis a Accusé Copilot  |  Votre Second Hébergeur Git S'Est Activé Seul