✨︎ Resumen (TL;DR):
- GitHub publicó el 20 de agosto de 2026 la explicación de la interrupción del 17 de agosto, que duró 7 horas y 47 minutos y afectó la web, la API, Actions, Pull Requests, la autenticación empresarial y Copilot.
- Una política de autoescalado vigiló el servicio anfitrión en vez de los límites del sidecar de Istio, que llegó a su límite de concurrencia.
- Los commits mensuales subieron de 1,400 millones en abril a 2,900 millones, mientras Azure ya atiende cerca de 58% de la carga de la plataforma.
GitHub publicó el 20 de agosto de 2026 el análisis 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. Vladimir Fedorov, director de tecnología de la compañía, la atribuyó a un pico de tráfico y a un componente crítico del centro de datos de Central US que no escaló; el informe técnico identifica una política de autoescalado que vigilaba el servicio anfitrión en lugar de los límites del sidecar de Istio.
La interrupción fue la segunda grande de GitHub en agosto. Ocurrió de las 13:28 a las 21:15 UTC. En Ciudad de México, el mismo periodo fue de las 07:28 a las 15:15, prácticamente la jornada laboral completa.
La explicación pública resume el problema como una falta de capacidad ante el crecimiento del tráfico. El análisis de causa raíz del panel de estado añade el detalle que no aparece en el blog: la política estaba configurada para observar el servicio anfitrión, no los límites del componente que se estaba saturando.
El autoescalado vigiló el límite equivocado
Sidecar de Istio es un componente de una malla de servicios que acompaña a cada servicio y administra su tráfico de red.
El pod del sidecar alcanzó su límite de concurrencia y no escaló. La política de autoescalado miraba el servicio anfitrión, por lo que no reaccionó a la saturación del sidecar.
La falla se propagó hasta cuatro nodos de HAProxy, que agotaron sus límites de flujo. Eso degradó la ruta de autenticación del gateway y provocó latencia y fallas generalizadas de autenticación. La lógica optimista de reintentos empeoró el cuadro y sobrecargó los balanceadores internos.
GitHub consiguió la recuperación amplia 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 se originaron en un cambio de código o configuración. Ambas fueron fallas de capacidad, según su explicación.
El 17 de agosto no hubo un despliegue reciente, pero sí una configuración incorrecta que ya existía. El informe del incidente de Actions del 6 de agosto dice que un despliegue rutinario dejó al descubierto una debilidad previa de capacidad y concurrencia.
La recuperación fue por etapas
GitHub registró esta secuencia en el panel de estado:
- 13:28 UTC: Comienzan los errores y la latencia elevada.
- 13:40 UTC: GitHub abre el incidente en su panel de estado.
- 16:36 UTC: La mayoría de los servicios se recupera junto con el centro de datos de Central US.
- 18:03 UTC, aproximadamente: Actions deja de estar degradado.
- 21:02 UTC: GitHub restablece por completo Copilot Token Service.
- 21:15 UTC: GitHub cierra el incidente y publica la causa raíz.
VS Code multiplicó por diez el tráfico
Mientras GitHub depuraba la falla de red, movió parte del tráfico que estaba fallando de Central US a Northern Virginia. Esa región atendió el tráfico sin problemas, pero las respuestas demoradas de un solo endpoint interno activaron un error de reintentos latente en VS Code.
El error amplificó el tráfico aproximadamente 10 veces. Copilot Token Service pasó de su rango normal de 7,000 a 9,000 solicitudes por segundo a entre 70,000 y 100,000.
GitHub frenó ese aumento al reducir temporalmente los reintentos del gateway mediante un pull request. También bloqueó con 403 las peticiones de token en los balanceadores y después devolvió el tráfico sitio por sitio.
El informe agrega un factor externo: varios ataques de scraping contra los endpoints de codeload, que sirven las descargas de repositorios.
Mientras la caída seguía en vivo, GitHub todavía no tenía la causa y reportaba cerca de 20% de errores en la web y el tráfico de API, además de cerca de 50% en las descargas de archivos y de contenido sin procesar.
2,900 millones de commits al mes
La publicación acompaña el diagnóstico con cifras de escala. GitHub reporta 2,900 millones de commits al mes. Sus gráficas muestran cerca de 130 millones de pull requests fusionados y 24 millones de repositorios nuevos.
En abril, cuando Fedorov firmó una nota anterior sobre disponibilidad, los commits mensuales llegaban a 1,400 millones. El volumen se duplicó en cuatro meses.
El plan para multiplicar por 10 la capacidad arrancó en octubre de 2025. Para febrero de 2026, GitHub concluyó que necesitaba diseñar para 30 veces la escala que tenía entonces.
Desde ahí, la compañía dice haber sumado más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento rápido. También instaló todo el hardware que la energía disponible permitía en sus centros de datos.
La nube de Microsoft ya atiende cerca de 58% de la carga de la plataforma, frente al 12% que atendía en mayo, y la mitad de las operaciones de Git.
El siguiente objetivo anunciado 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. GitHub no publicó una fecha para ese cambio.
Otra falla quedó abierta el 20 de agosto
El blog salió a las 18:36 UTC del jueves 20. Para entonces, el panel de estado llevaba casi cuatro horas con otro incidente abierto. GitHub lo había reportado a las 14:43 UTC y minutos después lo describió como demoras para iniciar tareas del Copilot Cloud Agent, que además dejaron de mostrar su progreso.
GitHub aclaró que las tareas sí se completaban. A las 20:37 UTC, el panel todavía reportaba una recuperación gradual y la salida de las sesiones se retrasaba alrededor de una hora.
Las correcciones apuntan a los límites y los reintentos
El informe promete acciones de seguimiento dirigidas a los puntos que fallaron:
- Corregir las políticas de autoescalado para que consideren la concurrencia del sidecar.
- Auditar los límites de Istio.
- Revisar los reintentos y el backoff en gateways y clientes.
- Atender el comportamiento de VS Code.
- Mejorar el monitoreo de la capacidad de los balanceadores y el failover entre regiones.
La publicación de Vladimir Fedorov, director de tecnología de GitHub, abre para quienes intentaban publicar software ese lunes con una frase breve: “te fallamos”.
Para los equipos que dependen de GitHub, Actions concentra el dato de disponibilidad más bajo. El servicio que ejecuta la integración y el despliegue continuos registra 99.33% de disponibilidad en los últimos 90 días, la cifra más baja entre los servicios que GitHub lista.
Cursor lanzó Origin, una 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. Hasta que lleguen, la referencia sigue siendo el panel de estado, que solo en agosto registró incidentes en Actions, Pages, la API GraphQL, Pull Requests, Webhooks, Team Sync y Copilot.
