Qué le pasó a GitHub el 17 de agosto de 2026: anatomía de una caída y cinco lecciones

Reescrito en octubre de 2026 a partir del análisis de causa raíz que publicó GitHub y del post de su CTO. La primera versión, del 19 de agosto, era una crónica con lo que se sabía entonces.

El 17 de agosto de 2026, GitHub estuvo casi ocho horas fallando: Issues, Pull Requests, la API, Actions, Copilot y la autenticación de empresa. Ya no interesa tanto qué pasó como por qué: la cadena de fallos es de manual, y casi todos sus eslabones existen también en infraestructuras mil veces más pequeñas. Esto es el postmortem leído con calma y lo que me llevo de él.

En 30 segundos

7 horas y 47 minutos (de 13:28 a 21:15 UTC), con picos de error de un 20 % en web y API y de un 50 % en descargas de archivos y contenido de repositorios.
Ningún cambio de código ni de configuración: fue un fallo de capacidad ante un pico de tráfico nuevo.
La pieza que no escaló: un sidecar de Istio cuyo autoescalado vigilaba la carga del servicio, no la del propio sidecar.
Lo que alargó la recuperación: los reintentos. Un fallo latente en VS Code multiplicó por diez el tráfico del servicio de tokens de Copilot.

Cronología

Hora (UTC)	Qué pasó
13:28	Empieza el incidente: errores generalizados en web y API
—	Parte del tráfico se desvía de Central US a Northern Virginia, donde sí responde
16:36	La mayoría de los servicios se recupera, con errores algo elevados
18:03	Actions deja de estar degradado
21:02	El servicio de tokens de Copilot se recupera del todo
21:15	Incidente resuelto

La cadena del fallo, eslabón a eslabón

Un pico de tráfico nuevo lleva a la saturación de red a los balanceadores de la región Central US.
Un sidecar de Istio —el proxy que acompaña a cada servicio en la malla y gestiona su tráfico— llega a su límite de concurrencia y no escala: su política de autoescalado miraba la carga del servicio principal, no los límites del sidecar.
La presión se propaga hasta que cuatro nodos HAProxy agotan sus límites de flujos.
Se degrada la ruta de autenticación del gateway. Como casi todo necesita autenticarse, el fallo deja de ser local: latencia y errores en toda la plataforma, incluidas SAML/OIDC, SCIM y Team Sync.
La lógica de reintentos optimista remata la faena: cada petición fallida vuelve a entrar y carga todavía más unos balanceadores ya saturados.

No falló una pieza: falló el supuesto de que la métrica vigilada era la que saturaba primero. Lo demás fue una reacción en cadena.

Por qué tardó tanto: la tormenta de reintentos

A las 16:36 casi todo funcionaba, pero Copilot no se recuperó del todo hasta las 21:02. El tráfico de su servicio de tokens pasó de 7.000–9.000 peticiones por segundo a 70.000–100.000. El análisis lo atribuye a un fallo latente en VS Code: cuando un endpoint interno tardaba en responder, el cliente reintentaba, y esos reintentos multiplicaron el tráfico por diez. Para rematar, unos ataques de scraping contra los endpoints de descarga complicaron la recuperación.

La salida fue contraintuitiva: bloquear las peticiones de tokens con un 403 en los balanceadores y reducir los reintentos del gateway. Rechazar deliberadamente fue lo que dejó respirar al sistema para volver a abrirlo después, por partes.

Cómo lo apagaron

Desviar parte del tráfico de Central US a Northern Virginia.
Pausar HAProxy en los nodos afectados, con una recuperación inmediata y amplia.
Reducir temporalmente los reintentos del gateway en Northern Virginia.
Bloquear con 403 las peticiones al servicio de tokens de Copilot en los balanceadores.
Restaurar el tráfico poco a poco, sitio por sitio, para que los clientes pudieran completar sus peticiones.
Cortar los bucles de reintento de los clientes, que eran la causa de los fallos residuales de Copilot.

Lo que GitHub va a cambiar

Del análisis de causa raíz:

Autoescalado que tenga en cuenta la concurrencia y la capacidad de los sidecars de la malla.
Auditoría de los límites de peticiones, concurrencia y escalado de Istio en los servicios afectados.
Revisión de los límites de reintento y del backoff en gateways y clientes, y arreglo del comportamiento de VS Code.
Mejor monitorización de la capacidad de los balanceadores y salvaguardas para la conmutación entre regiones.

Y del post de su CTO, que habla de la plataforma entera: más de 3 millones de núcleos y 120 PB de almacenamiento rápido añadidos, el 58 % de la carga ya en Azure (frente al 12 % de mayo), límites y presupuestos de reintento en todas las llamadas entre servicios, aislar los sistemas críticos quitando dependencias compartidas, y revisar las alertas de CPU y memoria de baja prioridad que podrían anticipar el próximo cuello de botella.

¿Y los agentes de IA?

En los días siguientes circuló que la causa era una avalancha de pull requests generadas por agentes de IA. El análisis oficial no lo menciona: habla de un pico de tráfico sin atribuirlo a nadie. Lo único relacionado con la IA en el informe es Copilot, y su papel fue el de víctima y amplificador por culpa de un cliente que reintentaba mal, no el de detonante. Es un buen recordatorio de leer el postmortem antes que el hilo viral.

Cinco lecciones para infraestructuras mucho más pequeñas

Escala por lo que satura primero, no por la métrica que tienes a mano. CPU y memoria son cómodas de medir, pero lo que se agota suele ser otra cosa: conexiones, hilos, descriptores de fichero, el pool de la base de datos o, como aquí, un proxy al lado del servicio. Pregúntate cuál es tu sidecar.
Cada reintento es carga nueva. Backoff exponencial con algo de aleatoriedad (jitter), un número máximo de intentos y un presupuesto de reintentos (que no puedan ser más que una fracción pequeña del tráfico). Y también en tus propios clientes: aquí el que multiplicó el tráfico por diez fue un cliente de la casa.
La autenticación es la dependencia de todo lo demás. Cuando falla, deja de ser un fallo de un servicio y pasa a ser un fallo de la plataforma. Merece capacidad holgada, aislamiento y alertas propias.
Rechazar rápido también es recuperarse. Un 403, 429 o 503 deliberado y barato es mejor que miles de peticiones a medio responder. Y al volver, abrir por partes, no todo de golpe.
Ten un plan B para tus dependencias. Git es distribuido: cualquier clon es una copia completa del repositorio. Lo frágil suele ser lo que cuelga alrededor, como el CI o el despliegue. Esta web, por ejemplo, tiene el código en GitHub pero se publica desde mi máquina: si GitHub cae, sigo pudiendo publicar.