El 17 de agosto de 2026 GitHub estuvo roto casi ocho horas: fallaban Issues, Pull Requests, la API, Actions y Copilot. Lo interesante del postmortem no es la falla original —una de capacidad, aburrida y previsible— sino cómo un detalle que casi todos tenemos en producción, los reintentos automáticos del cliente, convirtió un problema acotado en un incidente global que se retroalimentó a sí mismo. Es un caso de estudio perfecto sobre cómo la resiliencia mal calibrada se vuelve el arma del ataque.
El outage de GitHub del 17 de agosto de 2026 fue una caída de 7 horas y 47 minutos (13:28–21:15 UTC) provocada por una falla de capacidad en su data center de Central US: un sidecar de Istio llegó a su límite de concurrencia y el autoscaling no lo detectó. Los reintentos automáticos de los clientes, sobre todo un bug latente en VS Code, amplificaron el tráfico cerca de 10x y prolongaron el incidente durante horas.
¿Qué falló exactamente en el data center de GitHub?
Fue una falla de capacidad, no un deploy roto. Según el blog oficial de GitHub, el tráfico alcanzó un pico nuevo y un componente crítico de infraestructura en el data center de Central US no escaló con él. En concreto, un sidecar de Istio —el proxy que intercepta el tráfico de cada servicio en la malla— llegó a su límite de concurrencia y saturó los load balancers internos.
El detalle que transforma un hipo en un outage largo fue de observabilidad: la política de autoscaling estaba monitoreando el servicio anfitrión, no el límite de concurrencia del sidecar. El proxy se ahogaba mientras las métricas de CPU y memoria del host se veían tranquilas, así que el escalado nunca se disparó. Como resume el propio GitHub:
"Ninguna de las dos caídas fue causada por un cambio de código o de configuración. Ambos incidentes fueron, en el fondo, fallas de capacidad."
El contexto ayuda: de acuerdo con GitHub, los commits mensuales pasaron de 1.400 millones en abril de 2026 a 2.900 millones en agosto. La plataforma crecía más rápido de lo que su monitoreo de capacidad seguía.
¿Cómo un bug de retry en VS Code multiplicó el tráfico 10x?
Los reintentos de los clientes convirtieron una latencia elevada en una tormenta de tráfico. Cuando el refresh de los tokens de autenticación empezó a dar timeout, los clientes no esperaron ni aplicaron backoff: reintentaron de inmediato, en loop apretado. El Copilot Token Service, que normalmente maneja entre 7.000 y 9.000 RPS, pasó a recibir entre 70.000 y 100.000 RPS según el reporte del incidente —una amplificación de 8 a 14 veces.
El culpable más visible fue la extensión de Copilot en VS Code. Como reportó The Register, "las respuestas demoradas a un único endpoint interno dispararon un bug latente de retry en VS Code que amplificó el tráfico aproximadamente 10x". Ese loop corría en millones de laptops al mismo tiempo: cada instalación de VS Code se transformó, sin saberlo, en un pequeño generador de carga apuntando al mismo servicio ya caído.
Esta es la trampa del retry storm (o thundering herd): mientras el backend intenta recuperarse, la avalancha de reintentos lo mantiene saturado. El sistema no puede levantarse porque su propia clientela, comportándose "correctamente", lo sigue tirando abajo. El impacto se sintió parejo: al pico, el error rate de web y API rondó el 20%, y las descargas de archivos y raw content llegaron al ~50%.
¿Cómo cortó GitHub el retry storm?
Rompiendo el loop a la fuerza y volviendo a subir tráfico de a poco. GitHub no pudo simplemente "agregar capacidad": mientras el retry storm siguiera, cualquier capacidad nueva se consumía al instante. Los pasos que estabilizaron el sistema, según el hilo del incidente, fueron dos:
- Reducir los reintentos en el gateway. Desplegaron un PR que recortó la lógica de retry a nivel de gateway, para dejar de propagar la amplificación servicio a servicio.
- Bloquear en el borde y rampear. Los load balancers empezaron a rechazar las requests al Copilot Token Service con un HTTP 403, cortando la avalancha en seco, y después fueron habilitando tráfico gradualmente por sitio para que los clientes pudieran ir teniendo éxito sin volver a saturar.
La recuperación fue escalonada: la mayoría de los servicios volvió cerca de las 16:36 UTC, Actions alrededor de las 18:03 UTC y el Copilot Token Service recién a las 21:02 UTC. El incidente se dio por cerrado a las 21:15 UTC. Casi cuatro horas de la caída fueron, en la práctica, el sistema peleándose contra sus propios reintentos.
¿Qué patrones evitan que los retries amplifiquen una caída?
La lección es que un reintento sin límites es un multiplicador de carga, no una red de seguridad. La buena noticia es que las defensas son concretas y desplegables en tu propio cloud server, la mayoría a nivel de service mesh (Istio, Linkerd) sin tocar el código de la aplicación:
- Backoff exponencial con jitter. No reintentes a intervalo fijo. Escalá el tiempo entre intentos y sumale aleatoriedad, para que mil clientes no vuelvan a golpear todos en el mismo milisegundo.
- Presupuestos de retry (retry budgets). Limitá los reintentos a un porcentaje del tráfico real (por ejemplo, 20%). Si se supera, se dejan de reintentar aunque falle: es lo que GitHub anunció como remediación central.
- Circuit breakers. Si un servicio devuelve errores en cadena, cortá el circuito y fallá rápido en vez de seguir empujando requests a algo que ya está caído.
- Timeouts variables y acotados. Timeouts por intento cortos y con variación, para que un endpoint lento no se transforme en un embudo que acumula conexiones.
- Load shedding en el borde. Rechazar tráfico temprano (como el 403 de GitHub) es feo, pero le da al backend el oxígeno para recuperarse.
En Istio, limitar los reintentos y el timeout por intento de un servicio se hace declarativamente en un VirtualService:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: token-service
spec:
hosts:
- token-service
http:
- route:
- destination:
host: token-service
retries:
attempts: 2
perTryTimeout: 1s
retryOn: connect-failure,refused-stream,unavailableY el circuit breaker (outlier detection) vive en un DestinationRule, que expulsa temporalmente a las instancias que devuelven errores 5xx en cadena:
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: token-service
spec:
host: token-service
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 5
interval: 10s
baseEjectionTime: 30sEl concepto de retry budget que GitHub adoptó lo expone nativamente Linkerd en su ServiceProfile (en Istio/Envoy se configura vía EnvoyFilter):
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
name: token-service.default.svc.cluster.local
spec:
retryBudget:
retryRatio: 0.2
minRetriesPerSecond: 10
ttl: 10sCon retryRatio: 0.2, los reintentos nunca superan el 20% del tráfico base: exactamente el freno que a GitHub le faltó tener activo.
Qué te llevás de este postmortem
La resiliencia sin límites es fragilidad disfrazada. El incidente de GitHub muestra tres cosas que aplican a cualquier arquitectura de microservicios, por chica que sea:
- Monitoreá la capa que realmente satura. El autoscaling miraba el host, no el sidecar. Si tu métrica de escalado no cubre el cuello de botella real (proxy, pool de conexiones, límite de concurrencia), no vas a escalar cuando importa.
- Todo retry necesita un techo. Backoff, jitter, budget y circuit breaker no son adornos: son lo que separa una degradación de un outage de ocho horas.
- Tus clientes son parte del sistema. Un bug de retry en el cliente (VS Code) causó tanto daño como la falla de infraestructura. Diseñá el servidor asumiendo que los clientes van a comportarse mal bajo presión.
Si venís siguiendo la racha de caídas grandes de 2026, este caso rima con la nota sobre los 13 incidentes de Cloudflare y la caída de R2 que publicamos en el blog: distintas empresas, misma familia de problema —la resiliencia mal calibrada amplificando el fallo original—. Vale leerla como complemento.
Preguntas frecuentes
¿Cuánto duró el outage de GitHub del 17 de agosto de 2026?
Duró 7 horas y 47 minutos, de 13:28 a 21:15 UTC, según el postmortem oficial de GitHub. La mayoría de los servicios se recuperó cerca de las 16:36 UTC, pero el Copilot Token Service no se estabilizó hasta las 21:02 UTC.
¿Cuál fue la causa raíz del incidente?
Una falla de capacidad: un sidecar de Istio en el data center de Central US llegó a su límite de concurrencia y saturó los load balancers internos. La política de autoscaling monitoreaba el servicio anfitrión y no el límite del sidecar, así que el escalado nunca se disparó.
¿Qué es un retry storm o thundering herd?
Es cuando muchos clientes reintentan una request fallida al mismo tiempo y esa avalancha de reintentos mantiene saturado al backend, impidiendo que se recupere. En este caso el Copilot Token Service pasó de 7.000–9.000 RPS a 70.000–100.000 RPS por los reintentos.
¿Qué papel tuvo VS Code en la caída?
Un bug latente de retry en la extensión de Copilot para VS Code amplificó el tráfico cerca de 10x, según reportó The Register. Al fallar el refresh de tokens, la extensión reintentaba en loop sin backoff, y ese comportamiento corría en millones de instalaciones a la vez.
¿Cómo se evita que los reintentos amplifiquen una caída?
Con backoff exponencial más jitter, presupuestos de retry (limitar los reintentos a un porcentaje del tráfico), circuit breakers y timeouts por intento cortos. En un service mesh como Istio o Linkerd se configuran de forma declarativa, sin tocar el código de la aplicación.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
