Résumé
- L’incident classé majeur a duré de 07:53:59.358 à 09:39:19.558 UTC, soit 1 heure 45 minutes 20,200 secondes.
- GitHub a répertorié Actions, Issues, Webhooks et Pull Requests parmi les services touchés.
- Les tâches Actions pouvaient démarrer plus lentement et la recherche dans Issues renvoyer des résultats périmés.
- GitHub a annoncé à 09:22:21 UTC avoir identifié la source de la latence et appliqué un correctif, tandis que les files de traitement se résorbaient.
- Le fournisseur a promis une analyse détaillée de la cause sans publier encore le mécanisme, le nombre d’utilisateurs touchés ou une perte financière.
Une page qui répond lentement signale clairement un problème. Une page qui répond avec une information périmée est plus ambiguë: elle semble fonctionner, mais la décision qui en découle peut être fausse.
GitHub a indiqué que la recherche dans Issues pouvait présenter des résultats anciens. Une équipe pouvait donc ne pas voir un ticket récent, croire qu’une tâche n’existait pas ou travailler sur une priorité dépassée. Le registre d’incident ne dit pas que ces erreurs se sont produites; il montre le risque informationnel créé par le symptôme.
Ce risque coexistait avec des tâches Actions plus longues à démarrer, des Webhooks dégradés et des Pull Requests ralenties. L’information, l’automatisation, la livraison d’événements et la revue ne progressaient plus au même rythme.
Chaque surface est revenue selon sa propre chronologie
L’incident a commencé à 07:53:59.358 UTC. GitHub a d’abord mentionné Actions, Issues et Webhooks, puis ajouté Pull Requests.
Issues a été déclaré mitigé à 09:18:37, Actions à 09:19:49 et Pull Requests à 09:27:35. GitHub a indiqué que Webhooks fonctionnait normalement à 09:35:17. La résolution générale est intervenue à 09:39:19.558.
À 09:22:21, le fournisseur a déclaré avoir identifié la source de la latence et appliqué un correctif. Les services restants s’amélioraient au fur et à mesure que les files de traitement se vidaient.
Cette séquence sépare la correction technique de la remise à niveau. Une demande nouvelle peut être traitée alors qu’un travail plus ancien attend encore. Le client doit décider s’il patiente, relance ou annule, avec un risque de doublon ou de désordre si la demande initiale finit par s’exécuter.
GitHub n’a signalé aucun volume de doublons. Le coût observable est le besoin de vérification.
La transparence réduit une partie du coût client
Le message sur les résultats périmés permet de ne pas confondre absence dans la recherche et absence dans le système. L’information sur les files invite à éviter des relances aveugles.
Les équipes supportent néanmoins le travail de rapprochement: contrôler quelles tâches ont démarré, quels événements ont été livrés et quelles revues reflètent l’état courant. Ce temps ne figure pas dans le registre de disponibilité.
GitHub n’a publié ni nombre d’organisations touchées, ni volume de tâches, ni estimation financière. La durée de 1 h 45 min 20 s ne peut donc pas être multipliée par une valeur inventée.
Le fournisseur affirme avoir identifié la source mais ne nomme pas le composant ni le défaut. Il promet une analyse détaillée. Attribuer l’incident à une base de données, un déploiement ou un prestataire externe dépasserait les faits disponibles.
Cet épisode est distinct du retard des runners hébergés du 22 juillet: produits, horaires et symptômes ne coïncident pas. Deux incidents proches ne prouvent pas une cause commune.
La future analyse devra expliquer le déclencheur, la propagation entre services, les protections insuffisantes et la gestion des files. D’ici là, la leçon économique est celle de l’état incertain: lorsque la plateforme de coordination répond avec retard, le client paie aussi pour vérifier ce qui est vrai.