GitHub cayó 7 h 47 min: los reintentos multiplicaron por diez el tráfico
GitHub sufrió el 17 de agosto de 2026 una caída ya resuelta de 7 horas y 47 minutos, entre las 13:28 y las 21:15 UTC. El parte oficial de GitHub Status registró picos de error cercanos al 20 % en la web y las API y al 50 % en las descargas de archivos y contenido sin procesar.
La interrupción comenzó cuando una política de autoescalado no reaccionó al límite de concurrencia de un componente auxiliar de Istio en Central US. La cascada alcanzó los balanceadores HAProxy y la autenticación; durante la recuperación, un fallo latente de reintentos en VS Code elevó aproximadamente diez veces el tráfico del servicio de tokens de Copilot, una secuencia corroborada por la revisión técnica de IT Pro.
La incidencia afectó al núcleo de GitHub
Los errores alcanzaron Issues, Pull Requests, API Requests, Git Operations, Actions, Pages, Webhooks y Copilot. También se degradaron SAML, OIDC, SCIM y Team Sync, además de los flujos de Actions de GitHub Enterprise Cloud con residencia de datos que dependían de definiciones públicas alojadas en GitHub.com.
La restauración no ocurrió de una sola vez. La mayoría de los servicios se recuperó hacia las 16:36 UTC, al estabilizarse el centro de datos de Central US; Actions permaneció degradado aproximadamente hasta las 18:03 y Copilot Token Service no volvió por completo hasta las 21:02. La diferencia separa dos fases del incidente: la saturación que derribó la plataforma y la tormenta de solicitudes que mantuvo afectado a Copilot.
El autoescalado no veía el límite que importaba
El detonante fue un nuevo máximo de tráfico en Central US. Un sidecar de Istio alcanzó su límite de concurrencia, pero la política de autoescalado observaba el servicio principal y no la capacidad del componente auxiliar. Aunque el cuello de botella ya impedía procesar más solicitudes, la señal utilizada para añadir recursos no reflejaba esa restricción.
La presión se propagó por la red hasta que cuatro nodos HAProxy agotaron sus límites de flujo. Esto degradó la ruta de autenticación del gateway y extendió la latencia y los errores a servicios que dependían de ella. La lógica interna de reintentos agravó la carga sobre los balanceadores; pausar HAProxy simultáneamente en los nodos afectados produjo una recuperación amplia.
GitHub describió el episodio como un fallo de capacidad y aclaró que no lo desencadenó un cambio de código o configuración realizado ese día. Esa explicación no elimina la política mal configurada documentada en el análisis técnico: indica que el defecto era latente y quedó expuesto cuando la demanda superó la capacidad disponible.
VS Code prolongó la caída de Copilot
Parte del tráfico fallido se trasladó de Central US a Northern Virginia, donde inicialmente pudo atenderse. Después, las respuestas demoradas de un único endpoint interno activaron un error latente en el comportamiento de reintentos de VS Code: una operación de token fallida podía generar numerosas solicitudes adicionales y entrar en un bucle.
Copilot Token Service pasó de sus 7.000–9.000 solicitudes por segundo habituales a entre 70.000 y 100.000. Ese aumento cercano a diez veces explica por qué Copilot continuó sufriendo fallos de autenticación cuando buena parte de GitHub.com ya se había recuperado. Ataques de extracción automatizada contra endpoints de codeload añadieron presión, pero GitHub no los identificó como causa inicial.
VS Code, por tanto, no originó la saturación de Central US. Su error de reintentos fue un factor amplificador que dificultó la recuperación de Copilot después de iniciada la cascada principal. El incidente también mostró el riesgo de combinar reintentos internos del gateway con clientes que repiten agresivamente una misma operación.
Cómo se detuvo la tormenta de solicitudes
Para estabilizar Northern Virginia, GitHub redujo temporalmente la lógica de reintentos del gateway mediante un cambio de código. Los equipos también bloquearon en los balanceadores las solicitudes entrantes de tokens de Copilot con respuestas 403 y restauraron después el tráfico de forma gradual, sitio por sitio.
La mitigación atacó los dos lados del bucle: redujo las repeticiones dentro de la infraestructura y evitó que nuevas respuestas volvieran a activar el comportamiento defectuoso del cliente. Al disminuir el trabajo acumulado, las operaciones comenzaron a completarse y dejaron de producir cadenas adicionales de solicitudes.
La consecuencia técnica trasciende este incidente: los reintentos necesitan presupuestos y límites compartidos, pausas crecientes y tiempos variables para que los clientes no vuelvan a un servicio saturado al mismo ritmo. GitHub se comprometió específicamente a revisar los límites y el retroceso de los reintentos en gateways y clientes, además de corregir el comportamiento de VS Code.
Las correcciones anunciadas aún deben demostrar su eficacia
Las acciones posteriores incluyen corregir el autoescalado para considerar la concurrencia y capacidad de los sidecars, auditar los límites de solicitudes y escalado de Istio, vigilar mejor la capacidad de los balanceadores y reforzar la conmutación regional. GitHub también aplicará límites, presupuestos de reintentos y tiempos variables más consistentes entre servicios.
En la actualización corporativa del 20 de agosto, la empresa afirmó haber añadido más de tres millones de núcleos de CPU, 120 petabytes de almacenamiento de alta velocidad y capacidad de red adicional mientras acelera la migración a Azure. En ese momento, Azure atendía alrededor del 58 % de la carga de la plataforma y la mitad de las operaciones Git, frente al 12 % de la carga en mayo.
La incidencia figura como resuelta y la cadena causal está documentada. Lo que todavía no se ha publicado son resultados de pruebas que permitan comprobar cómo responderán las correcciones ante otro pico comparable ni un calendario detallado para completar todas las medidas anunciadas.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.