GitHub tombe 7 h 47 le 17 août 2026, et la panne est un problème de capacité, pas un bug
Le 20 août 2026, le CTO de GitHub a publié le post-mortem de la panne du 17 août : 7 h 47 d’indisponibilité causées par un composant d’infrastructure qui n’a pas suivi la montée en charge, alors que les commits mensuels sont passés de 1,4 à 2,9 milliards depuis avril. La leçon pour les équipes SRE tient en deux mots : retry budgets.
17 août 2026. GitHub tombe en panne pendant 7 heures et 47 minutes, touchant github.com, l’authentification, les Actions, les API, les pull requests, les issues et Copilot. 20 août 2026. Vlad Fedorov, le CTO, publie le post-mortem officiel. Entre avril et août 2026. Les commits mensuels sont passés de 1,4 milliard à 2,9 milliards.
La conclusion du post-mortem tient en une phrase, et elle dérange : aucune des deux pannes d’août n’a été causée par un changement de code ou de configuration. Les deux étaient des pannes de capacité.
Une panne de capacité, pas un incident logiciel
Le récit de GitHub est inhabituellement direct. L’enquête a établi que la panne a commencé quand le trafic a atteint un nouveau pic, et qu’un composant d’infrastructure critique du datacenter Central US n’a pas réussi à monter en charge avec lui. La pression de capacité qui en a résulté s’est propagée à travers les systèmes, provoquant des échecs d’authentification et la dégradation de plusieurs services.
C’est la deuxième panne majeure du mois, après un incident sur les Actions le 6 août. Et ce n’est pas la première fois que GitHub communique sur le sujet : en mars et avril 2026, l’entreprise avait déjà détaillé ses chantiers de fiabilité. Le message du 20 août est qu’ils doivent être accélérés.
Le diagnostic est assumé : GitHub n’a pas fait évoluer ses composants critiques avant que la demande ne dépasse leur capacité. Depuis avril, les commits mensuels ont doublé. Cette croissance explique la pression — mais elle n’excuse pas la panne. La nuance compte, parce qu’elle déplace la responsabilité du « bug imprévisible » vers le « dimensionnement insuffisant », qui est, lui, une décision d’ingénierie.
Ce que révèle la phase de récupération
La récupération a demandé plusieurs actions coordonnées : réacheminer le trafic, isoler l’infrastructure touchée, puis restaurer les services par étapes. La plupart des services sont revenus le jour même, mais certains services Copilot ont pris plus de temps.
C’est là que le post-mortem livre sa leçon la plus concrète. Les erreurs de ces services ont déclenché une boucle de retry côté client qui a augmenté le trafic pendant la récupération. L’équipe a dû neutraliser ce comportement avant de pouvoir restaurer le trafic en sécurité.
C’est le retry storm classique : sous la charge, un service échoue ; les clients réessaient en masse ; les retries créent une charge supplémentaire ; le service échoue encore plus. La panne se nourrit elle-même. La réponse immédiate de GitHub a été d’appliquer des limites de retry, des budgets de retry et des timeouts variables cohérents sur toutes les interactions service-à-service, pour empêcher les tempêtes de retries et la charge en cascade.
La stratégie : capacité, Azure et isolement
Le post-mortem détaille trois priorités engagées depuis le début de l’année : ajouter de la capacité, améliorer l’efficacité, supprimer les goulots d’étranglement architecturaux. Les chiffres sont massifs : plus de 3 millions de cœurs CPU ajoutés, 120 pétaoctets de stockage haute vitesse, et une capacité réseau significative. GitHub a installé autant de matériel que la puissance électrique disponible le permettait, tout en accélérant sa migration vers Azure.
Le point le plus notable est la bascule d’infrastructure : Azure sert désormais environ 58 % de la charge de la plateforme et la moitié des opérations Git, contre 12 % de la charge en mai. Cette empreinte étendue a aussi absorbé la croissance des exécutions de jobs Actions.
Deux chantiers complètent le tableau. D’abord, isoler les systèmes critiques et supprimer les dépendances partagées entre eux, pour réduire la probabilité d’une panne et en limiter le rayon. Ensuite, la promesse d’une architecture qui fait évoluer la capacité de lecture linéairement avec le nombre de lecteurs, en commençant par les plus gros monorepos. C’est l’aveu que le modèle actuel plafonne sur les dépôts géants.
Enfin, l’équipe passe en revue les alertes CPU et mémoire de basse priorité pour repérer les composants susceptibles de céder lors d’un pic soudain. Un signal faible ignoré est un incident qui attend.
Verdict
Si vous construisez sur GitHub, traitez cette panne comme un argument de supply chain, pas comme une anecdote : une plateforme qui héberge votre CI/CD est un composant critique dont la disponibilité conditionne la vôtre. L’entreprise qui en dépend le plus a intérêt à avoir un plan de secours — miroir de dépôt, export régulier, et une chaîne de déploiement qui ne s’arrête pas net quand l’authentification centrale tombe.
Si vous opérez des services, la leçon est actionnable dès cette semaine. La cause racine — un composant qui ne suit pas la montée en charge — et l’aggravateur — le retry storm — sont deux échecs évitables. Instrumentez vos budgets de retry et vos timeouts variables, et traitez vos alertes de capacité de basse priorité comme des signaux de pré-incident : quand un service approche de son plafond, le moment d’agir est avant le pic, jamais pendant.
Si vous voulez un indicateur simple : GitHub a doublé ses commits mensuels en quatre mois et sa panne a duré 7 h 47. La prochaine fois que votre équipe repousse un chantier de capacité « à plus tard », rappelez-vous que la croissance ne prévient pas, elle sature.