Introducción
El 17 de agosto de 2026, GitHub dejó de funcionar durante siete horas y cuarenta y siete minutos. Autenticación, APIs, Actions, Copilot, pull requests, issues: toda la plataforma cayó de forma simultánea, dejando a millones de desarrolladores sin su herramienta central de trabajo. No era el primer incidente del mes — GitHub ya había sufrido una interrupción de más de siete horas en Actions el 6 de agosto. Pero la magnitud del día 17 y, sobre todo, la precisión del postmortem publicado tres días después, convierten este caso en una referencia ineludible sobre la fragilidad de las infraestructuras cloud modernas.
Una cascada de fallos, no un error aislado
La causa raíz no fue un despliegue fallido, ni una vulnerabilidad de software, ni un ciberataque. Fue un fallo de capacidad desencadenado por un volumen de tráfico sin precedentes.
El origen del problema: un sidecar de Istio — el componente encargado de mediar las comunicaciones entre servicios en un entorno de service mesh — alcanzó su límite de procesamiento concurrente en el centro de datos estadounidense de GitHub. El problema crítico: el mecanismo de auto-scaling monitorizaba el estado del servicio principal, no el de su sidecar. Ninguna alerta activó el escalado. Cuatro servidores HAProxy, los balanceadores de carga internos de la plataforma, absorbieron el exceso hasta saturarse, bloqueando los flujos de autenticación y generando un efecto dominó sobre el conjunto de los servicios.
Un segundo mecanismo agravó considerablemente la duración del incidente: un bug latente en el cliente VS Code de Copilot que reintentaba las llamadas fallidas sin límite alguno. Este comportamiento multiplicó el volumen de solicitudes por diez — de 7 000 a 9 000 peticiones por segundo en condiciones normales a más de 100 000 durante la crisis. La tormenta de reintentos, fenómeno ampliamente documentado en arquitecturas distribuidas, imposibilitó cualquier intento de estabilización durante varias horas.
El crecimiento que fragiliza
Existe un dato de contexto que lo ilumina todo: los commits mensuales procesados por GitHub pasaron de 1 400 millones en abril a 2 900 millones en agosto, es decir, se duplicaron en cuatro meses. Un crecimiento impulsado en gran medida por la adopción masiva de herramientas de automatización y asistencia al código, que generan volúmenes de commits incomparables con las prácticas manuales tradicionales.
Este ritmo transforma de raíz los cálculos de capacidad. Una infraestructura dimensionada seis meses antes puede volverse insuficiente mucho antes de la próxima revisión anual. Y cuando las curvas de crecimiento se disparan, los puntos ciegos de la observabilidad — como una política de auto-scaling que no cubre todos los componentes de una cadena crítica — se convierten en vulnerabilidades estructurales.
Las medidas puestas en marcha
Antes la magnitud del incidente, GitHub anunció varias acciones concretas: incorporación de más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento, aceleración de la migración hacia la infraestructura de Azure — que ya absorbe aproximadamente el 58 % de la carga de la plataforma —, limitación de las políticas de reintento en los servicios críticos, y refuerzo del aislamiento entre componentes para evitar que un fallo localizado se propague al conjunto del sistema.
Lo que esto implica para los equipos de infraestructura
Este incidente pone de manifiesto una realidad incómoda: en las arquitecturas de service mesh modernas, la observabilidad parcial es tan peligrosa como la ausencia total de observabilidad. Monitorizar un servicio sin vigilar sus dependencias directas — sidecars, proxies, load balancers — genera puntos ciegos que solo se revelan en condiciones extremas.
Para los equipos responsables de infraestructuras críticas, las lecciones son claras: las configuraciones de auto-scaling deben cubrir la totalidad de la cadena de procesamiento, las políticas de reintento deben auditarse de forma periódica, y los planes de capacidad deben anticipar curvas de crecimiento no lineales. Lo que este postmortem documenta con una precisión poco habitual es la anatomía de una caída que muchas organizaciones — mucho más allá del propio GitHub — corren el riesgo de reproducir.