GitHub reportó cinco incidentes de disponibilidad en agosto: el más largo duró 10 horas y 42 minutos

GitHub publicó el 10 de septiembre de 2026 su informe de disponibilidad de agosto, en el que detalla cinco incidentes que afectaron a servicios como GitHub Actions, las APIs REST y GraphQL, Issues, pull requests, GitHub Copilot y GitHub Pages. El más largo, el del 6 de agosto, duró 10 horas y 42 minutos; los otros se registraron el 17 de agosto (7 horas y 35 minutos), el 20 de agosto (9 horas y 54 minutos), el 26 de agosto (2 horas y 50 minutos) y el 27 de agosto (2 horas y 8 minutos), todos con horarios expresados en UTC por la propia empresa. Los resúmenes de impacto que acompañan cada caso consignan duraciones aproximadas que no siempre coinciden con las de los encabezados, una diferencia que el informe no explica. El episodio del 6 de agosto, iniciado a las 15:22 UTC, dejó a al menos 74 organizaciones con flujos de trabajo de Actions que no arrancaban, fallaban a mitad de camino o quedaban en cola mucho más tiempo de lo habitual. El del 17 de agosto, desde las 13:40 UTC, fue el de mayor alcance: en el pico, el 56,07% de las solicitudes a los servicios afectados fallaron o corrieron lentas en el borde, y a lo largo de toda la ventana unas 29.000 organizaciones —conjuntos de cuentas de usuario que administran repositorios, según la definición del propio informe— registraron al menos una solicitud fallida o lenta, sobre un total cercano a 4,8 millones. GitHub aclara que no se perdieron datos. El 20 de agosto, a partir de las 14:43 UTC, el problema se concentró en Copilot: una región de la base de datos administrada donde el agente en la nube guarda el estado y los resultados de cada tarea sufrió una caída del proveedor, y al menos 54 organizaciones vieron esos estados y resultados demorados hasta 60 o 90 minutos por encima de su nivel habitual. Las tareas siguieron ejecutándose y completándose; lo que se retrasó fue la visibilidad de su estado. El 26 de agosto, desde las 15:11 UTC, un pico de eventos sobre una base de datos compartida que ya venía cerca de su límite hizo que los runs de Actions no arrancaran: al menos 24 organizaciones quedaron por encima de su línea de base y 386 registraron algún impacto en el inicio de runs, con más de uno de cada cinco inicios fallando o demorándose en el minuto de mayor carga. El último, el 27 de agosto a las 10:04 UTC, no dependió de la infraestructura propia: el 63,3% de los pedidos al modelo Kimi K3 de Copilot fallaron por una degradación del proveedor externo que lo sirve.

Detrás de los cinco episodios hay un patrón que el propio informe describe sin vueltas: servicios corriendo cerca de sus límites de capacidad y mecanismos de escalado automático que no reaccionaron a tiempo. En el caso del 6 de agosto, un despliegue de rutina sobre un servicio interno de Actions redujo brevemente la cantidad de pods —las unidades en que se ejecuta un servicio— en un sitio, y aunque el contenido del despliegue no era el problema (GitHub lo revirtió para confirmarlo), esa pérdida momentánea de capacidad empujó a los sitios restantes por encima de su límite. Los sidecars del service mesh, los componentes que intermedian el tráfico entre servicios, empezaron a sufrir throttling de CPU y reinicios por falta de memoria, y eso se propagó en errores de caché, DNS y API. Cuando los servicios centrales empezaron a recuperarse, un bug latente en la asignación de jobs hizo que los runners recibieran trabajos ya revocados y quedaran atascados reintentándolos, lo que armó una cola que se amplificaba a sí misma. El 17 de agosto la causa fue un pico nuevo de tráfico que llevó a los balanceadores de carga de un datacenter más allá de sus límites: un sidecar del service mesh alcanzó su límite de concurrencia y no escaló, varios nodos agotaron sus límites de flujo de red y se degradó el camino compartido de autenticación, con lo que cayeron servicios que rutean por ese datacenter. Un bug latente de reintentos del lado del cliente amplificó el tráfico hacia un endpoint interno de autenticación y demoró la recuperación del Copilot Token Service. El 20 de agosto el origen fue externo: una región de la base de datos administrada que usa Copilot cloud agent sufrió una caída del proveedor, los procesadores que escriben el estado de las tareas quedaron atrás y una configuración de almacenamiento hizo que la región tardara en hacer failover, es decir, en pasar a otra región sana. El 26 de agosto, una ráfaga de eventos sobre una base de datos compartida ya exigida saturó la primaria, y como no existía un circuit breaker automático que cortara la carga entrante ante los primeros signos de estrés, el throttling tuvo que aplicarse y ajustarse a mano. El 27 de agosto, finalmente, fue una degradación del proveedor externo que sirve el modelo Kimi K3.

El informe llega después de un mes que la propia empresa califica de difícil en materia de disponibilidad, y se apoya en un antecedente que GitHub menciona: la nota que publicó el mes anterior sobre la caída del 17 de agosto y el trabajo que queda por delante. Según la empresa, la plataforma sigue creciendo de forma significativa mientras avanza una inversión agresiva en mejoras arquitectónicas y en la migración a Azure, que le dará más capacidad. El informe admite que, aun priorizando el trabajo de mayor impacto y minimizando el riesgo, los incidentes de agosto muestran que el riesgo no se puede eliminar por completo, y resume su criterio en una frase que ordena las prioridades: "disponibilidad, después capacidad, después funcionalidades".

Además de los arreglos puntuales de cada incidente, el informe repasa una serie de avances que la empresa presenta como estructurales. El 11 de agosto GitHub corrió por primera vez una base de datos MySQL primaria de producción desde Azure, con impacto mínimo en las escrituras observadas por los clientes y sin afectación para los usuarios en la transición, y repitió la operación con otras dos primarias el 27 de agosto; hay más programadas para las próximas semanas, con complejidad creciente. El tráfico de lectura también marcó máximos: las lecturas de servicios migrados llegaron al 60,4%, las del monolito de GitHub al 64,3% en Azure y las lecturas de Git al 54%. En paralelo, una cohorte de 24 tablas de autenticación salió de mysql1, la base de datos compartida más antigua de GitHub, con lo que se quitaron aproximadamente un millón de consultas por segundo a sus réplicas, y otros cambios de higiene de consultas eliminaron 120.000 consultas por segundo y unos 59.000 segundos de trabajo desperdiciado por hora. En Actions, cambios en el ruteo de jobs movieron el 33% de los trabajos desde un clúster saturado hacia capacidad libre, bajaron el uso pico de CPU de caché del 98% al 80% y sumaron unos tres meses de margen; la empresa aclara que se trata de una contención de corto plazo y no de la meta final. También avanzó el aislamiento de pull requests (las lecturas autenticadas de la primera cohorte de producción llegaron al 100%) y las protecciones contra sobrecarga de Git, que sirvieron 6,4% más de tráfico con una mejora del 24% en la duración del percentil 95 y del 78% en la demora máxima. Desde el 21 de agosto, la detección automática de incidentes de alto impacto combina señales de soporte al cliente con telemetría de servicios. Para el próximo mes quedan pendientes la migración de las siguientes bases de datos primarias, seguir moviendo servicios y tráfico a Azure, la salud de las bases compartidas, más automatización de capacidad y autoescalado, y extender el manejo de fallas de dependencias en la experiencia de pull requests.