Le 17 août 2026, GitHub est resté indisponible sept heures et quarante-sept minutes. L’authentification, Actions, l’API, les pull requests, les issues et Copilot sont tombés avec, et un très grand nombre d’équipes ont passé une partie de cet après-midi à chercher si c’était leur propre build qui avait cassé.
Cette question - est-ce nous ou est-ce eux - mérite qu’on sache y répondre en deux minutes plutôt qu’en deux heures, et les indices qui y répondent disparaissent avec la fin de l’incident.
Les indices, dans l’ordre où ils servent
Quel hôte tombe. Ouvrez l’onglet Réseau et regardez où vont les requêtes qui échouent. Un 500 venu de votre propre domaine est à vous. Un 503 venu d’une API que vous n’exploitez pas ne l’est pas, quelle que soit l’impression que votre fonctionnalité est cassée. Cela paraît évident et c’est l’étape que l’on saute, parce que le symptôme apparaît dans votre interface et que l’interface est ce que l’on a sous les yeux.
Ce que dit le code de statut. Un 401 ou un 403 pendant l’incident d’authentification de quelqu’un d’autre n’est pas un bug de permissions dans votre code, et c’est celui que l’on classe le plus souvent comme tel. Un 429 est une limite de débit et peut être la conséquence de vos propres réessais. Un timeout sans aucune réponse pointe vers l’extérieur plus souvent que vers l’intérieur.
S’il coïncide avec votre déploiement. La première question dans n’importe quel canal d’incident est de savoir ce qui a changé. Si votre dernière release date de trois heures avant le début des symptômes, cela mérite d’être dit dans le premier message et pas dans le cinquième.
Ce que dit leur page de statut, consultée en deuxième et non en premier. Les pages de statut sont mises à jour par des gens occupés à éteindre l’incendie, et elles ont quelques minutes de retard sur la panne. Votre propre onglet Réseau le sait avant leur page de statut.
Le piège : vos réessais peuvent aggraver les choses
La partie du récit de GitHub qui mérite deux lectures est ce qui s’est passé pendant la reprise. Leur propre post-mortem dit :
Les erreurs dans ces services ont déclenché une boucle de réessais côté client qui a augmenté le trafic pendant la reprise. Nous avons dû atténuer ce comportement avant de pouvoir rétablir le trafic sans risque.
Autrement dit, les clients qui s’acharnaient le plus à passer faisaient partie de ce qui gardait la porte fermée. La liste des mesures de GitHub nomme le correctif en termes généraux - “des limites de réessais cohérentes, des budgets de réessais et des timeouts variables sur les échanges entre services, pour éviter les tempêtes de réessais et la charge en cascade” - et c’est une phrase à tenir contre votre propre code.
Une logique de réessai écrite pour une requête isolée en échec se comporte autrement quand toutes les requêtes échouent. Sans budget, sans backoff et sans jitter, cent instances qui réessaient toutes selon le même calendrier deviennent un test de charge synchronisé dirigé vers un service qui peine déjà.
Il vaut aussi la peine de savoir qu’aucun des deux incidents d’août chez GitHub ne venait d’un changement de code ou de configuration. Les deux étaient des défauts de capacité. Le réflexe de chercher le déploiement fautif a généralement raison et avait tort ici.
Capturez-le pendant que c’est cassé
Une panne est la seule catégorie de défaut qui se répare toute seule, et les preuves partent avec elle. Deux heures plus tard, la requête qui renvoyait un 503 renvoie un 200, et le ticket porte “échec intermittent, non reproductible” jusqu’à la fin de ses jours.
Ce qu’il vous faut, pris pendant l’incident : les requêtes en échec avec leurs codes de statut et leurs temps, la sortie de la console, et l’heure à laquelle chacune s’est produite.
Session Replay
Extension Chrome gratuite. Un clic sur la page qui se comporte mal capture la copie d'écran, la console et le journal réseau, et vous rend un lien à coller dans le ticket.
Le journal réseau contient un fichier HAR, c’est-à-dire exactement l’artefact que le support d’en face vous demandera de toute façon. Nettoyez-le avant de le transmettre : un HAR enregistré avec les contenus embarque des cookies de session et des en-têtes d’autorisation, et c’est la seule chose dans ce flux de travail qui a déjà provoqué une fuite dans une autre entreprise.
L’écrire pour qu’il ne soit pas mal classé
Un compte rendu d’incident et un rapport de bug sont deux documents différents, et les confondre coûte une matinée à un développeur.
Si la panne est celle de quelqu’un d’autre, dites-le dans le titre, et dites ce que cela signifie pour vous : quelle fonctionnalité est touchée, s’il existe un contournement, et ce que vous attendez. “Paiement en échec - le prestataire de paiement en amont renvoie 503 depuis 14h10, aucun contournement, leur page de statut le reconnaît” est un rapport complet. Personne n’a besoin de le reproduire, et personne ne devrait essayer.
Si c’est peut-être le vôtre, c’est un rapport de bug ordinaire et il demande les choses ordinaires : ce que vous attendiez, ce qui s’est passé, l’environnement et les preuves. Notre guide pour en écrire un en donne la forme, et les dix erreurs les plus courantes couvrent ce qui manque d’habitude.
Et si vous n’en savez vraiment rien encore, écrivez-le. “On ne sait pas si c’est chez nous - les requêtes en échec vont vers un hôte externe, mais notre release est partie à 13h30” est plus utile qu’une supposition assurée dans un sens ou dans l’autre.
Après coup
Deux questions qui valent la peine une fois l’incident terminé, tant que les gens s’en souviennent.
Combien de temps nous a-t-il fallu pour savoir que ce n’était pas nous ? Si la réponse est une heure, le correctif tient d’habitude à la visibilité plutôt qu’à la résilience : un endroit où regarder qui montre quels hôtes sont en échec.
Nos réessais ont-ils aidé ou nui ? GitHub a dû atténuer le comportement des clients avant de pouvoir rétablir le trafic. Vos clients sont le comportement client de quelqu’un d’autre.
Sources : le récit que GitHub fait de l’incident se trouve dans The August 17 outage, and the work ahead, et il est exceptionnellement précis sur ce qui a mal tourné. Publié tout à leur honneur, et cité ici parce qu’un post-mortem qui nomme les tempêtes de réessais est plus utile que n’importe quel conseil à leur sujet.