GitHub a révélé la cause exacte de la panne de huit heures survenue le 17 août , qui a paralysé des millions de développeurs à travers le monde. Au plus fort de la panne, le taux d'erreur du site web et de l'API avoisinait les 20 %, et le téléchargement d'archives et de fichiers bruts échouait dans près de la moitié des cas. La plupart des services sont revenus à la normale après environ trois heures, mais GitHub Actions et le service de jetons Copilot sont restés instables bien plus longtemps. D'après le rapport publié, tout a commencé par un pic de trafic soudain et inhabituel dans l'un des centres de données de GitHub aux États-Unis. On peut comparer la situation à celle d'un magasin où dix fois plus de clients que d'habitude font la queue à une seule caisse. Le système, censé ouvrir automatiquement des caisses supplémentaires (c'est-à-dire augmenter la puissance de traitement), a dysfonctionné car il surveillait un indicateur de charge incorrect. Par conséquent, un composant de l'infrastructure interne s'est rapidement retrouvé saturé. La congestion s'est étendue, les serveurs supplémentaires chargés de la gestion du trafic et des connexions utilisateur atteignant eux aussi leurs limites. Ceci a directement impacté le processus d'authentification, entraînant des ralentissements, voire des échecs, de connexion et d'autorisation. Pire encore, le système, censé relancer automatiquement les connexions ayant échoué, a au contraire envoyé davantage de requêtes aux serveurs déjà surchargés.

Lorsque GitHub a tenté de rediriger une partie du trafic vers un centre de données de secours en Virginie, un autre problème est apparu : un bug dans l’éditeur VS Code a provoqué une surcharge du serveur de connexion Copilot par des tentatives de connexion répétées. Normalement, ce service traite entre 7 000 et 9 000 requêtes par seconde. Pendant la panne, ce nombre a grimpé jusqu’à 100 000 par seconde. GitHub a géré la situation en limitant les tentatives de reconnexion automatiques, en bloquant temporairement certaines requêtes et en rétablissant progressivement et avec précaution le trafic normal. L'infrastructure de GitHub ne peut tout simplement pas suivre le rythme de la popularité croissante du codage assisté par l'IA. L'entreprise elle-même a admis en début d'année qu'elle devait privilégier la stabilité aux nouvelles fonctionnalités, et Microsoft a même envisagé d'acheter de la puissance de calcul auprès d'Amazon. Comparée aux pannes précédentes, plus courtes, celle-ci a duré beaucoup plus longtemps et a affecté simultanément davantage de services critiques. Pour les entreprises et les équipes utilisant GitHub Actions, cela signifie une interruption de service et le risque d'une nouvelle panne jusqu'à la mise en œuvre des correctifs annoncés. Et cela ne peut pas être résolu en deux semaines…