Contexte de l'incident

Le 12 octobre 2026, GitHub a publié une alerte indiquant une dégradation de performance affectant les services Actions, Pull Requests et Issues. L’incident a été signalé à 12:21 UTC, suivi d’une mise à jour à 12:33 UTC confirmant l’enquête en cours. À 12:57 UTC, les équipes ont détaillé les symptômes observés, puis à 13:02 UTC ont indiqué que le service Pull Requests fonctionnait à nouveau. La dernière mise à jour, à 13:38 UTC, précise que la mitigation initiale n’était pas totalement efficace et que des retards persistent.

Composants affectés et symptômes

Les rapports mentionnent plusieurs points de défaillance : lenteur du chargement de l’interface Actions, erreurs lors de l’appel à l’API Checks, blocage de la mise en file d’attente des nouvelles exécutions d’Actions, difficultés à créer ou mettre à jour des issues, et retards dans les demandes de revue de pull requests via les API REST et GraphQL. En outre, les notifications web sont retardées, ce qui indique un problème dans le pipeline de webhook.

Analyse des causes potentielles

GitHub Actions repose sur une architecture distribuée : un front‑end API, une couche de persistance (base de données relationnelle) et un système de file d’attente qui distribue les jobs aux runners. Un goulot d’étranglement au niveau de la base de données peut augmenter la latence de toutes les opérations dépendantes, y compris la création d’issues et la mise à jour des PR. De même, une saturation du service de queueing ralentit le déclenchement des runs et empêche le rafraîchissement de l’interface UI, qui interroge fréquemment l’API pour afficher l’état des workflows. Les retards de webhook suggèrent que le service de diffusion d’événements, qui consomme les changements de statut depuis la même base de données, subit également une charge accrue.

Mesures d'atténuation et perspectives

GitHub a indiqué avoir mis en place une mitigation en cours de suivi, probablement en augmentant temporairement la capacité des workers ou en appliquant un throttling sur les requêtes API afin de stabiliser la charge. La persistance du problème après la première mitigation indique que le correctif n’a pas résolu le goulet d’étranglement principal, ou que la charge résiduelle dépasse les seuils de redondance. La surveillance continue des métriques de latence et des taux d’erreur sera indispensable pour valider la récupération complète. En l’absence de détails supplémentaires, il reste difficile de confirmer la cause exacte, mais l’incident souligne la sensibilité d’une plateforme monolithique où plusieurs services partagent les mêmes ressources de stockage et de queueing.