TL;DR:
- GitHub publicó el 20 de agosto de 2026 su explicación de la caída del lunes 17, que duró 7 horas y 47 minutos y afectó la web, la API, Actions, Pull Requests, la autenticación empresarial y Copilot.
- El análisis de causa raíz ubica el origen en un pod sidecar de Istio que no escaló porque la política de autoescalado vigilaba el servicio anfitrión y no los límites del sidecar.
- Los commits mensuales pasaron de 1,400 millones en abril a 2,900 millones, y Azure ya atiende cerca de 58% de la carga de la plataforma.
GitHub publicó el jueves 20 de agosto de 2026 su explicación de la caída del lunes 17, la segunda interrupción grande del mes en la plataforma. El incidente duró 7 horas y 47 minutos, de las 13:28 a las 21:15 UTC, que en la Ciudad de México fueron de las 07:28 a las 15:15, prácticamente la jornada laboral completa. Vladimir Fedorov, director de tecnología de la compañía, la atribuye a un pico de tráfico y a un componente crítico del centro de datos de Central US que no escaló con él. El análisis de causa raíz que GitHub publicó en su panel de estado agrega la pieza que el blog no menciona: ese componente no escaló porque una política de autoescalado vigilaba el servicio anfitrión y no los límites del sidecar que se estaba saturando.
El autoescalado vigilaba el límite equivocado
La cadena que describe el informe empieza en un pod sidecar de Istio, la pieza que acompaña a cada servicio dentro de la malla y administra su tráfico de red. Ese pod llegó a su límite de concurrencia y no escaló. Una falla arrastró a otra hasta que cuatro nodos de HAProxy agotaron sus límites de flujo y degradaron la ruta de autenticación del gateway, con latencia y fallas de autenticación generalizadas. La lógica optimista de reintentos empeoró el cuadro y sobrecargó los balanceadores internos. La recuperación amplia llegó al pausar HAProxy en esos nodos al mismo tiempo.
En el blog, Fedorov sostiene que ni esta caída ni la de Actions del 6 de agosto salieron de un cambio de código o de configuración, y que las dos fueron fallas de capacidad. Detrás del lunes 17 no hubo un despliegue reciente, pero sí una configuración que ya estaba mal puesta. Y el informe de aquel incidente del 6 de agosto dice que lo disparó un despliegue rutinario, que dejó al descubierto una debilidad previa de capacidad y concurrencia.
El documento también fija que la recuperación fue por etapas y no en un solo momento:
| Hora del 17 de agosto (UTC) | Hecho registrado por GitHub |
|---|---|
| 13:28 | Empiezan los errores y la latencia elevada |
| 13:40 | GitHub abre el incidente en su panel de estado |
| 16:36 | La mayoría de los servicios se recupera junto con el centro de datos de Central US |
| 18:03 (aprox.) | Actions deja de estar degradado |
| 21:02 | El Copilot Token Service queda restablecido por completo |
| 21:15 | GitHub cierra el incidente y publica la causa raíz |
Un error latente en VS Code multiplicó por diez el tráfico
Parte del tráfico que fallaba se movió de Central US a Northern Virginia, donde se atendió sin problema mientras se depuraba la falla de red. Ahí apareció el segundo frente. Las respuestas demoradas de un solo endpoint interno activaron un error de reintentos que estaba latente en VS Code y que amplificó el tráfico unas diez veces. El Copilot Token Service pasó de un rango normal de 7,000 a 9,000 solicitudes por segundo a entre 70,000 y 100,000. GitHub frenó la tormenta reduciendo de forma temporal los reintentos del gateway con un pull request y bloqueando con un 403 las peticiones de token en los balanceadores, para después devolver el tráfico sitio por sitio.
El informe suma un factor externo que estorbó la recuperación: varios ataques de scraping contra los endpoints de codeload, los que sirven las descargas de repositorios.
Cuando seguimos la caída en vivo, GitHub todavía no tenía causa y solo cuantificaba el daño: cerca de 20% de errores en la web y el tráfico de API, y cerca de 50% en las descargas de archivos y de contenido sin procesar.
Dilis Salazar
De 1,400 a 2,900 millones de commits al mes
El blog acompaña la explicación con cifras de escala: 2,900 millones de commits al mes y, según las gráficas que publica, cerca de 130 millones de pull requests fusionados y 24 millones de repositorios nuevos. En abril, cuando Fedorov firmó su nota anterior sobre disponibilidad, los commits mensuales llegaban a 1,400 millones. Se duplicaron en cuatro meses.
Ese texto de abril ya había dejado dicho el tamaño del problema: el plan para multiplicar por diez la capacidad arrancó en octubre de 2025 y, para febrero de 2026, la compañía concluyó que necesitaba diseñar para 30 veces la escala de entonces. Desde ahí, GitHub dice haber sumado más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento rápido, e instaló todo el hardware que la energía disponible permitía en sus centros de datos.
La otra mitad de la respuesta es Azure. La nube de Microsoft ya atiende cerca de 58% de la carga de la plataforma, contra 12% en mayo, y la mitad de las operaciones de Git. El siguiente objetivo que anuncia la empresa es una arquitectura que escale la capacidad de lectura de forma lineal con el número de lectores, empezando por los monorepos más grandes.
El mismo día del análisis, otro incidente abierto
El blog salió a las 18:36 UTC del jueves 20. Para entonces, el panel de estado de GitHub llevaba casi cuatro horas con otra falla abierta: la reportó a las 14:43 UTC y minutos después la describió como demoras para iniciar tareas del Copilot Cloud Agent, que además dejaron de mostrar su progreso. La compañía aclaró que las tareas sí se completaban. A las 20:37 UTC seguía reportando recuperación gradual, con la salida de las sesiones retrasada alrededor de una hora.
Las acciones de seguimiento que promete el informe apuntan a lo que falló: corregir las políticas de autoescalado para que consideren la concurrencia del sidecar, auditar los límites de Istio, revisar reintentos y backoff en gateways y clientes, atender el comportamiento de VS Code y mejorar el monitoreo de capacidad de los balanceadores y el failover entre regiones.
El blog abre con una frase corta para quien intentaba publicar software ese lunes: "te fallamos".
Para los equipos que dependen de la plataforma, la lectura práctica está en el mismo tablero. Actions, el servicio que ejecuta la integración y el despliegue continuos, aparece con 99.33% de disponibilidad en los últimos 90 días, la cifra más baja entre los servicios que GitHub lista. La competencia ya se movió: Cursor lanzó Origin, su alternativa para alojar código y revisar pull requests.
GitHub no publicó fecha para los nuevos límites de reintentos ni para la arquitectura de lectura que anuncia. Hasta que lleguen, la referencia sigue siendo su panel de estado, que solo en agosto registró incidentes en Actions, Pages, la API GraphQL, Pull Requests, Webhooks, Team Sync y Copilot.
