GitHub reveló detalles de cinco incidentes que afectaron a la disponibilidad de sus servicios durante agosto de 2026, entre ellos interrupciones en GitHub Actions, retrasos en los resultados de Copilot Cloud Agent y fallos en las solicitudes al modelo Kimi K3. La empresa vincula los incidentes al crecimiento de la plataforma y a unos márgenes de capacidad reducidos, además de a defectos en el escalado automático, las políticas de reintento y los mecanismos de recuperación.
GitHub afirma que está invirtiendo en mejorar la arquitectura y migrar más servicios a Azure, dando prioridad a la disponibilidad, seguida de la capacidad y después de las funciones. También anunció mejoras en la supervisión de la capacidad, la gestión de colas, las políticas de reintento y la resiliencia de los servicios fundamentales.
Cinco incidentes con causas diferentes
- 6 de agosto: el incidente duró 10 horas y 42 minutos, después de que un despliegue rutinario de un servicio interno de Actions redujera temporalmente la capacidad en una de las ubicaciones. Esto provocó la saturación de los servicios y la propagación de errores al almacenamiento en caché, DNS y las API; posteriormente, un defecto en la ruta de asignación de tareas ralentizó la recuperación. Una proporción considerable de los flujos de trabajo falló o se retrasó, y algunos eventos tuvieron que reiniciarse manualmente.
- 17 de agosto: la degradación duró 7 horas y 35 minutos como consecuencia de que los balanceadores de carga de un centro de datos alcanzaran el máximo de su capacidad, mientras un componente auxiliar de la red de servicios no se escalaba pese a haber alcanzado su límite de concurrencia. Esto provocó retrasos y fallos en la ruta de autenticación compartida, y el impacto se extendió a Issues, Pull Requests, las API, Actions y Copilot. Además, un defecto en los reintentos duplicó el tráfico de solicitudes hacia un punto de autenticación interno.
- 20 de agosto: el incidente duró 9 horas y 54 minutos y afectó al estado y los resultados de las tareas de Copilot Cloud Agent en al menos 54 organizaciones. Una región del proveedor de bases de datos en la nube que almacena los estados de las tareas quedó inoperativa, y el cambio regional falló rápidamente debido a una configuración de almacenamiento, lo que provocó la acumulación de actualizaciones de estado. Las tareas en sí no se perdieron, pero la aparición de los resultados se retrasó hasta que se restableció el procesamiento y se vació la cola.
- 26 de agosto: la degradación duró 2 horas y 50 minutos, cuando una oleada de eventos llevó al límite de saturación a una base de datos compartida que ya funcionaba cerca de su capacidad máxima. Esto retrasó el inicio de las ejecuciones de Actions y afectó a servicios que dependían de ella, como Copilot Code Review y algunas operaciones de GitHub Pages. GitHub tuvo que limitar gradualmente la carga entrante, ya que no había un disyuntor automático que activara la protección al aparecer indicadores de sobrecarga.
- 27 de agosto: el incidente duró 2 horas y 8 minutos y afectó únicamente a las solicitudes dirigidas al modelo Kimi K3 dentro de Copilot debido a una degradación del proveedor externo del modelo. La tasa de fallos de estas solicitudes superó la mitad en el punto álgido del incidente, mientras que los demás modelos y la configuración Auto siguieron disponibles.
¿Qué cambió en la práctica?
Las medidas anunciadas muestran que GitHub aborda los incidentes como problemas de capacidad, aislamiento y recuperación, no solo como errores de despliegue aislados. La empresa trasladó el 33% de las funciones de Actions desde un clúster de producción restringido a capacidad de reserva, lo que redujo el uso del procesador de almacenamiento en caché en los picos del 98% al 80% y añadió, según su estimación, aproximadamente tres meses de margen. Asimismo, las lecturas de los servicios migrados a Azure alcanzaron un máximo del 60,4%, las del sistema monolítico llegaron al 64,3% y las de Git al 54%.
En cuanto a las bases de datos, el primer MySQL primary de producción en Azure se puso en funcionamiento el 11 de agosto sin un impacto apreciable en las operaciones de escritura observadas por los clientes; posteriormente, el mismo patrón se repitió con dos bases de datos fundamentales el 27 de agosto. GitHub también eliminó aproximadamente un millón de consultas por segundo de las réplicas de una base de datos antigua, mientras que otros cambios redujeron 120.000 consultas por segundo y cerca de 59.000 segundos de trabajo desperdiciado por hora.
¿Por qué es importante este informe?
Los incidentes muestran que depender únicamente del escalado horizontal no basta cuando los servicios comparten bases de datos, rutas de autenticación o una misma infraestructura de Actions. Además, los reintentos sin control pueden transformar una degradación parcial en una carga más amplia, mientras que un retraso en el cambio entre regiones puede provocar la acumulación de estados incluso cuando no se pierden las tareas originales. El plan de Azure y las medidas de aislamiento y los disyuntores de carga siguen en ejecución, por lo que el informe no demuestra que los riesgos hayan desaparecido; más bien, muestra dónde concentrará GitHub sus próximos esfuerzos: migrar más bases de datos fundamentales, automatizar la gestión de la capacidad y ampliar la gestión de los fallos de dependencias.