El 17 de agosto de 2026, GitHub.com dejó de funcionar con normalidad durante casi ocho horas. No fue un simple parpadeo: Issues, Pull Requests, la API, Actions, Copilot y hasta la autenticación empresarial (SAML/OIDC) quedaron degradados o directamente caídos para desarrolladores en todo el mundo. En las horas siguientes al incidente circuló una teoría llamativa —que la causa había sido una avalancha de pull requests generadas por agentes de IA— pero no es lo que dice el informe oficial. Repasamos aquí lo que realmente ocurrió, con fuentes contrastadas.
Cronología del incidente
El incidente comenzó a las 13:28 UTC y se dio por resuelto a las 21:15 UTC, un total de 7 horas y 47 minutos. La recuperación no fue uniforme: distintos servicios volvieron a la normalidad en momentos distintos.
| Hora (UTC) | Evento |
|---|---|
| 13:28 | Inicio del incidente — errores generalizados en web y API |
| 16:36 | La mayoría de los servicios se recupera |
| 18:03 | GitHub Actions se estabiliza |
| 21:02 | El servicio de tokens de Copilot se recupera por completo |
| 21:15 | Incidente marcado como resuelto |
Qué se vio afectado
La lista de servicios impactados fue larga:
- Issues y Pull Requests
- API general de GitHub
- GitHub Actions
- GitHub Copilot
- Autenticación empresarial: SAML/OIDC, SCIM y Team Sync
- Descargas de archivos y contenido raw de repositorios
- Webhooks y operaciones Git
En el pico del incidente, las tasas de error alcanzaron aproximadamente un 20% en tráfico web y de API, y llegaron hasta un 50% en descargas de archivos y contenido de repositorios. Para cualquier equipo que dependiera de GitHub para integración continua o control de versiones, la jornada quedó prácticamente parada.
La causa raíz: un fallo de autoescalado en la malla de servicios
Según el informe del propio GitHub, el origen no fue un ciberataque ni un cambio de código defectuoso, sino un problema clásico de infraestructura a escala: un pico de tráfico saturó los balanceadores de carga en la región Central US.
El detonante técnico fue un pod sidecar de Istio (la malla de servicios que gestiona el tráfico interno entre microservicios) que alcanzó sus límites de concurrencia sin escalar automáticamente. La causa de fondo: una política de autoescalado mal configurada, que monitorizaba la carga del servicio principal (host) pero no tenía en cuenta los límites propios del sidecar.
Ese punto ciego provocó una cascada de fallos: cuatro nodos HAProxy agotaron sus límites de flujo, lo que degradó la ruta de autenticación de la puerta de enlace (gateway) y arrastró consigo a servicios que dependían de ella, incluida la autenticación empresarial.
En resumen: no fue un fallo de un único componente, sino una cadena de dependencias mal dimensionadas —autoescalado, sidecar de Istio y balanceadores HAProxy— que colapsaron en secuencia ante un pico de tráfico.
Sobre el rumor de los agentes de IA
Durante y después del incidente circuló ampliamente una explicación alternativa: que agentes de codificación con IA estarían generando hasta 30 veces la carga para la que la infraestructura de GitHub fue diseñada, citando un crecimiento de pull requests abiertas por agentes de IA de unos 4 millones en septiembre de 2025 a más de 17 millones en marzo de 2026.
Es una teoría llamativa y probablemente refleja una presión real y creciente sobre la plataforma, pero no aparece en el informe oficial del incidente ni ha sido confirmada por GitHub como causa de esta caída concreta. Su origen rastreable es un artículo de blog especulativo, no un comunicado de la compañía. Conviene tratarla como lo que es —una hipótesis no verificada que circuló en redes— y no como un hecho establecido.
Cómo respondió GitHub
La mitigación se ejecutó en varios frentes simultáneos:
- Pausa de HAProxy en los nodos afectados para cortar la cascada de fallos.
- Reducción de la lógica de reintentos automáticos, que estaba amplificando la carga sobre un sistema ya saturado.
- Bloqueo de solicitudes con código de error 403 para aliviar presión adicional.
- Restauración gradual del tráfico, sitio por sitio, en lugar de una reactivación total de golpe.
Qué medidas preventivas anunció GitHub
Tras el incidente, GitHub comunicó varias líneas de trabajo para evitar que se repita:
- Auditar las políticas de autoescalado para que tengan en cuenta la concurrencia de los sidecars, no solo la del servicio host.
- Revisar los límites configurados en Istio en los servicios afectados.
- Auditar el comportamiento de reintentos tanto en clientes como en puertas de enlace, para evitar que un fallo puntual se amplifique en una tormenta de reintentos.
- Mejorar el monitoreo de capacidad de los balanceadores de carga, para detectar saturaciones antes de que se conviertan en cascadas de fallo.
Fuentes
- GitHub Community Discussion #205164 — hilo del incidente
- Pulsetic — seguimiento del incidente de GitHub
- GitHub Status — histórico de incidentes
Artículo actualizado a partir de fuentes públicas disponibles a 19 de agosto de 2026.