Résumé
- GitHub a ouvert le 19 juillet à 23 h 34 UTC un incident Actions classé critique. De nouveaux flux pouvaient démarrer en retard ou ne pas démarrer, tandis que des exécutions en cours pouvaient échouer.
- Les requêtes API, Pages et Issues ont ensuite été touchés. GitHub a reconnu que la durée de l'indisponibilité Actions produisait des effets en chaîne et a rattaché à l'incident principal les échecs Git LFS signalés séparément.
- CircleCI a vu des pipelines bloqués ou absents après des événements push. OpenAI a constaté des retards ou échecs dans des travaux de programmation dépendant de GitHub.
- Actions était entièrement rétabli à 04 h 43 UTC et l'incident a été clos une minute plus tard. GitHub promet une analyse détaillée de la cause, qui n'était pas publiée à la clôture de ce brefing.
Un commit peut être présent, le serveur de calcul disponible et la livraison pourtant immobile.
C'est le risque mis en évidence par la panne de GitHub entre dimanche soir et lundi matin. Le premier avis, publié à 23 h 34 UTC, concernait Actions. GitHub a rapidement précisé que les nouveaux flux pouvaient être retardés ou ne pas démarrer et que les exécutions déjà lancées pouvaient échouer. À 23 h 57, l'entreprise disait avoir trouvé la cause, sans la décrire.
Le périmètre s'est ensuite déplacé. Les requêtes API sont passées en panne partielle à 00 h 07. Pages et Issues ont été dégradés. Une autre fiche d'incident a signalé des opérations Git LFS et des chargements de fichiers par API en échec. À 01 h 11, GitHub a relié les points: l'arrêt prolongé d'Actions provoquait des effets sur d'autres services, et la seconde enquête portait sur la même chaîne.
Une panne d'exécution devient une panne de coordination
Actions exécute des tâches, mais son rôle ne se limite pas aux processeurs qui lancent les commandes. Un événement de dépôt déclenche un flux, le flux crée des travaux, un ordonnanceur les affecte à des runners et l'état retourné alimente les règles de fusion, les tableaux de suivi et des systèmes extérieurs.
Chaque maillon peut diverger. Le push existe mais son flux n'est jamais créé. Un travail s'exécute mais le statut attendu par une branche protégée n'arrive pas. Un gros fichier demeure dans LFS, alors que l'appel nécessaire pour le charger échoue. Une page déjà servie reste accessible tandis que sa prochaine construction est bloquée.
La chronologie de reprise confirme que ces surfaces ne se sont pas rétablies ensemble. Pages était revenu à 01 h 37, Issues à 02 h 20. À 02 h 43, GitHub annonçait le retour d'Issues, des API et de Pages, tout en poursuivant la restauration des travaux Actions utilisant des runners auto-hébergés ou de grande capacité. Les requêtes API ont été déclarées normales à 03 h 03. Actions est passé sous surveillance à 03 h 34, puis a été annoncé totalement rétabli à 04 h 43.
Ces heures décrivent les messages du fournisseur, pas la durée vécue par chaque client. GitHub n'a publié ni nombre de dépôts, ni taux d'échec global, ni ventilation géographique. Additionner les phases des différents composants produirait une fausse mesure.
CircleCI montre le coût d'un état incohérent
Le constat de CircleCI est le plus utile pour comprendre l'après-panne. Son état de service a attribué aux erreurs de l'API GitHub des flux qui ne démarraient pas ou restaient affichés comme en cours. La plateforme a aussi constaté des erreurs lors du traitement des webhooks liés aux push.
Après le retour des API, CircleCI a recommandé de relancer manuellement les pipelines qui n'avaient jamais commencé et d'annuler puis relancer ceux qui demeuraient bloqués. Cette consigne révèle le problème central: la reprise du fournisseur amont ne réconcilie pas automatiquement l'historique détenu par le service aval.
OpenAI a fourni une seconde confirmation indépendante. Sa page d'état a relié des retards ou échecs dans des flux de programmation dépendant de GitHub à la panne partielle des API et à la dégradation d'Actions. Elle ne chiffre ni utilisateurs ni travaux. Elle prouve plus modestement que l'incident a franchi la frontière de GitHub et s'est présenté sous une autre interface client.
Ces deux avis ne rendent pas les fournisseurs aval responsables de la panne. Ils montrent que la dépendance n'était pas théorique. Ils montrent aussi pourquoi un voyant vert chez GitHub ne suffit pas à certifier qu'un événement, un travail et son résultat sont cohérents partout.
Auto-héberger le runner ne suffit pas à auto-héberger le flux
GitHub définit un runner auto-hébergé comme une machine déployée et administrée par le client pour exécuter les travaux Actions. L'entreprise choisit le matériel, le système, les outils et porte les coûts d'exploitation.
Cette maîtrise répond à des besoins réels de sécurité, de localisation, de puissance ou d'accès au réseau interne. Elle ne recrée pas le plan de commande de GitHub.
Le détail publié à 02 h 43 est révélateur: même après le retour d'Issues, des API et de Pages, GitHub travaillait encore au rétablissement des travaux utilisant des runners auto-hébergés ou plus grands. Cela ne prouve pas que les machines des clients étaient en panne. Cela prouve que leur capacité de calcul restait tributaire de l'ordonnancement, des événements et de l'état gérés par GitHub.
Une voie de secours crédible doit donc répondre à des questions plus larges que la seule disponibilité d'un serveur. Qui déclenche le travail si l'événement normal n'est pas reçu ? Où se trouve la définition approuvée ? Comment l'état final revient-il dans la chaîne de revue ? Qui peut autoriser une livraison d'urgence, et quelle trace restera après coup ?
Relancer seulement après avoir vérifié la cible
Un travail indiqué comme échoué ou bloqué peut avoir déjà modifié un système extérieur. Il peut avoir publié un paquet, appliqué une évolution d'infrastructure, envoyé une notification ou commencé un déploiement avant de perdre son retour d'état.
Le relancer sans vérification peut donc dupliquer l'effet que l'on cherche à réparer. La bonne séquence consiste à rapprocher l'événement du dépôt, l'historique Actions, les journaux du runner, l'état des artefacts et le système cible. Des opérations idempotentes et un identifiant de livraison vérifiable réduisent le danger, mais ne remplacent pas ce rapprochement.
Pour un simple test, recommencer est souvent sans conséquence. Pour une modification partiellement appliquée en production, la reprise peut exiger une procédure spécifique. Le statut du pipeline ne doit jamais tenir lieu de preuve unique sur ce qui s'est réellement passé à l'extérieur.
La prochaine preuve doit expliquer la propagation
GitHub a clos l'incident à 04 h 44 et annoncé une future analyse détaillée. La fiche publique établit déjà l'ordre de dégradation et de reprise. Elle n'identifie pas le composant initial, la raison pour laquelle les API et les autres services ont été entraînés, ni les changements qui empêcheront une répétition.
Rien dans ces éléments ne permet d'affirmer une intrusion, une perte de code, un échec de déploiement chez un client précis ou un droit automatique à un crédit. La qualification « critique » appartient à la classification de GitHub; elle ne mesure pas la perte de chaque organisation.
L'explication utile devra séparer le défaut initial, l'accumulation de travaux et les effets produits pendant la reprise. En attendant, l'enseignement opérationnel est clair: la chaîne est revenue, mais un client ne devrait déclarer son propre incident terminé qu'après avoir vérifié que l'événement, le travail et la cible racontent la même histoire.