GitHub a révélé les détails de cinq incidents ayant affecté la disponibilité de ses services en août 2026, notamment des pannes de GitHub Actions, un retard dans les résultats de Copilot Cloud Agent et des échecs dans les requêtes adressées au modèle Kimi K3. L’entreprise relie ces incidents à la croissance de la plateforme et à la réduction des marges de capacité, ainsi qu’à des défauts de mise à l’échelle automatique, des politiques de nouvelle tentative et des mécanismes de récupération.
GitHub affirme investir dans l’amélioration de son architecture et dans la migration d’un plus grand nombre de services vers Azure, en donnant la priorité à la disponibilité, puis à la capacité et enfin aux fonctionnalités. L’entreprise a également annoncé des améliorations de la surveillance de la capacité, de la gestion des files d’attente, des politiques de nouvelle tentative et de la résilience des services essentiels.
Cinq incidents aux causes différentes
- 6 août : l’incident a duré 10 heures et 42 minutes, après qu’un déploiement de routine d’un service interne d’Actions a entraîné une réduction temporaire de la capacité sur l’un des sites. Cela a provoqué la saturation des services et la propagation d’erreurs au cache, au DNS et aux API, puis un défaut dans le chemin d’attribution des tâches a ralenti la récupération. Une grande partie des workflows a échoué ou a été retardée, et certains événements ont dû être relancés manuellement.
- 17 août : la dégradation a duré 7 heures et 35 minutes, les équilibreurs de charge d’un centre de données ayant atteint leur capacité maximale, tandis qu’un composant auxiliaire du réseau de services ne s’est pas mis à l’échelle malgré l’atteinte de sa limite de concurrence. Cela a entraîné des retards et des échecs dans le chemin d’authentification partagé, avec des répercussions sur Issues, Pull Requests, les API, Actions et Copilot. Un défaut de nouvelle tentative a également multiplié le trafic vers un point d’authentification interne.
- 20 août : l’incident a duré 9 heures et 54 minutes et a affecté l’état et les résultats des tâches de Copilot Cloud Agent dans au moins 54 organisations. Une région du fournisseur de bases de données cloud stockant l’état des tâches est tombée en panne, et le basculement régional a rapidement échoué en raison d’un paramètre de stockage, ce qui a entraîné l’accumulation des mises à jour d’état. Les tâches elles-mêmes n’ont pas été perdues, mais l’affichage des résultats a été retardé jusqu’à la reprise du traitement et la résorption de la file d’attente.
- 26 août : la dégradation a duré 2 heures et 50 minutes lorsqu’une vague d’événements a poussé une base de données partagée, qui fonctionnait près de sa limite, jusqu’à la saturation. Cela a retardé le démarrage des tâches Actions et affecté des services qui en dépendent, tels que Copilot Code Review et certaines opérations de GitHub Pages. GitHub a dû limiter progressivement la charge entrante, car aucun coupe-circuit automatique n’activait la protection à l’apparition des signes de surcharge.
- 27 août : l’incident a duré 2 heures et 8 minutes et n’a affecté que les requêtes dirigées vers le modèle Kimi K3 dans Copilot, en raison d’une dégradation chez le fournisseur externe du modèle. Le taux d’échec de ces requêtes a dépassé la moitié au plus fort de l’incident, tandis que les autres modèles et le paramètre Auto sont restés disponibles.
Qu’est-ce qui a changé concrètement ?
Les mesures annoncées montrent que GitHub traite les incidents comme des problèmes de capacité, d’isolation et de récupération, et non comme de simples erreurs de déploiement isolées. L’entreprise a transféré 33 % des tâches Actions d’un cluster de production contraint vers une capacité de secours, ce qui a réduit l’utilisation du processeur du cache au pic de 98 % à 80 % et ajouté, selon son estimation, environ trois mois de marge. Les lectures des services migrés vers Azure ont également atteint un pic de 60,4 %, contre 64,3 % pour les lectures du système monolithique et 54 % pour les lectures Git.
Au niveau des bases de données, le premier serveur primaire MySQL de production sur Azure a été mis en service le 11 août sans impact notable sur les opérations d’écriture observées par les clients, puis la même approche a été répétée avec deux bases essentielles le 27 août. GitHub a également supprimé environ un million de requêtes par seconde sur des répliques d’une ancienne base de données, tandis que d’autres modifications ont réduit de 120 000 requêtes par seconde le trafic et d’environ 59 000 secondes par heure le temps de travail gaspillé.
Pourquoi ce rapport est-il important ?
Les incidents montrent que la seule mise à l’échelle horizontale ne suffit pas lorsque les services partagent des bases de données, des chemins d’authentification ou une même infrastructure Actions. De même, des nouvelles tentatives mal maîtrisées peuvent transformer une dégradation partielle en charge plus étendue, tandis qu’un basculement interrégional tardif peut entraîner l’accumulation des états même lorsque les tâches d’origine ne sont pas perdues. Le plan Azure, les mesures d’isolation et les coupe-charge sont toujours en cours de mise en œuvre ; le rapport ne prouve donc pas que les risques ont été éliminés, mais il indique où GitHub concentrera ses prochains efforts : migrer d’autres bases essentielles, automatiser la gestion de la capacité et renforcer la gestion des défaillances des dépendances.