GitHub Actions subit une dégradation de disponibilité avec retards d'exécution

Contexte de l'incident

Le 5 octobre 2026, GitHub a publié une série de mises à jour indiquant une dégradation de disponibilité du service Actions. Les premières notifications, émises à 19:15 UTC, signalaient des performances réduites. À 19:50 UTC, l’équipe a identifié des retards dans l'attribution des runners hébergés, affectant le démarrage des workflows. Les messages d’update successifs, à 20:39, 20:47 et 21:09 UTC, ont confirmé des échecs de jobs et des délais d’exécution prolongés. En parallèle, certains utilisateurs ne pouvaient plus accéder aux listes de dépôts, aux pages de licences et de facturation.

Mécanisme de planification des runners

GitHub Actions repose sur un système de runners hébergés qui exécutent les jobs dans des conteneurs isolés. Lorsqu’un workflow est déclenché, le scheduler interroge le pool de runners disponibles, réserve une instance et transmet le job via une API interne. La disponibilité du pool dépend de la capacité de provisionnement dynamique et de la santé du réseau interne. Un goulot d’étranglement dans la couche d’orchestration, par exemple une surcharge de la file d’attente ou une panne de service de découverte, peut retarder l’assignation et provoquer des timeouts côté client.

Dans cet incident, les logs publiés par GitHub indiquent que les délais d’assignation se sont allongés de plusieurs minutes, alors que la norme habituelle est de quelques secondes. Cette anomalie suggère un problème de scalabilité du service de matchmaking, possiblement lié à une hausse soudaine du volume de jobs ou à une défaillance d’un composant de stockage d’état.

Analyse des impacts et limites

Les retards d’assignation ont entraîné une augmentation du temps moyen de démarrage des workflows, impactant les pipelines CI/CD critiques. Les équipes de développement ont observé des échecs de jobs lorsque les runners n’étaient pas disponibles avant l’expiration du timeout configuré (souvent 10 minutes). Cette situation a également affecté les services annexes, comme l’accès aux pages de licences et de facturation, probablement en raison d’une dépendance partagée à la même infrastructure de gestion d’identité.

Du point de vue de la résilience, l’incident met en évidence la nécessité d’une isolation plus stricte entre les services de planification et les API de gestion de compte. Une architecture à double‑pool, où les runners critiques sont séparés des services de facturation, pourrait limiter la propagation des pannes. De plus, l’exposition d’un point unique de défaillance dans le service de matchmaking justifie l’introduction de mécanismes de basculement automatisés.

GitHub a indiqué travailler à une mitigation, mais les communications n’ont pas fourni de métriques précises sur le nombre de jobs affectés ni sur la durée totale de la dégradation. L’absence de données chiffrées limite l’évaluation de l’impact économique pour les entreprises clientes.