GitHub reveló en su informe de disponibilidad de septiembre de 2026 dos incidentes que afectaron al rendimiento de sus servicios, junto con avances en la redistribución de la infraestructura y en la mejora de la capacidad de las bases de datos para soportar la presión. La empresa señala que los trabajos de remediación aún no han concluido, pese a la implementación de cambios destinados a reducir los riesgos de fallos cuando aumenta la carga o falla uno de los componentes compartidos.
Hasta el 7 de octubre, 120 de los 160 servicios de producción estaban desplegados en la región Central US, mientras que se habían trasladado 13 de las 51 bases de datos MySQL principales. Azure gestionaba el 65,4% del tráfico de lectura de la aplicación principal de GitHub, el 48,3% del tráfico de lectura de Git y el 80,2% del tráfico de procesamiento de flujos. La empresa confirma que estos porcentajes corresponden a cargas diferentes y no deben sumarse.
Avances en el traslado de la infraestructura, con retraso respecto al calendario
GitHub detuvo los despliegues y el aumento del tráfico en Central US el 11 de septiembre debido a una disparidad de capacidad entre las zonas de disponibilidad. Los aumentos permanentes se reanudaron el 18 de septiembre tras disponer de capacidad temporal, pero los trabajos de capacidad a largo plazo continúan, con el objetivo de habilitar toda la capacidad disponible para finales de octubre. La empresa no alcanzó su ambicioso objetivo de desplegar allí todos los servicios de producción para el 30 de septiembre.
Durante una conversión planificada de una base de datos, un procedimiento automatizado de emergencia separó las réplicas de las bases de datos en Central US, lo que provocó perturbaciones para los clientes de la región. GitHub desactivó este procedimiento durante las entregas planificadas hasta mejorar los mecanismos de recuperación.
Reducción de la presión sobre las bases de datos y contención de fallos
GitHub trasladó 24 tablas del sistema de autenticación principal fuera de su base de datos compartida más antigua, lo que eliminó aproximadamente un millón de consultas por segundo de las réplicas. También se eliminaron unos 980 millones de registros innecesarios del historial de cambios del clúster que respalda Issues y Pull Requests, lo que liberó aproximadamente 1,8 terabytes de almacenamiento recuperable. Los conflictos entre transacciones semanales disminuyeron alrededor de un 77% frente al máximo de junio.
La mitad del tráfico de Pull Requests incluido en la muestra podía continuar con funciones limitadas cuando fallaba una dependencia compartida. El direccionamiento del tráfico de las bases de datos también puede añadir capacidad automáticamente durante los picos; uno de los grupos se amplió de 14 a 19 réplicas durante un aumento de la actividad de Pull Requests el 23 de septiembre. GitHub añadió un mecanismo de control de carga que permite rechazar las solicitudes de menor prioridad antes de que los servicios alcancen una saturación más amplia.
Los dos incidentes de septiembre
El 13 de septiembre, una tarea de limpieza de datos en segundo plano provocó un aumento de la carga sobre una base de datos compartida. El mecanismo de protección supervisaba el retraso de las réplicas, pero no la carga acumulada en el servidor principal, que alcanzó el límite de conexiones disponibles. La ausencia de un tiempo de espera breve para las consultas hizo que los procesadores de solicitudes permanecieran a la espera, mientras un bucle de reintentos continuaba enviando operaciones de escritura fallidas. El incidente duró una hora y 28 minutos y terminó después de reducir la carga interna y detener la tarea.
El 28 de septiembre, un cambio en el servicio que ejecuta las revisiones de código de Copilot hizo que se enviara a algunos clientes una versión limitada de los resultados de la revisión en lugar de la versión completa que incluye los comentarios. Por ello, las tareas parecían completadas aunque las revisiones no aparecían en las solicitudes de extracción. El incidente duró 52 minutos y GitHub lo resolvió revirtiendo el cambio, además de pedir a los clientes que volvieran a solicitar las revisiones afectadas.
¿Qué cambia en la práctica?
Los dos incidentes muestran que las mejoras de capacidad por sí solas no son suficientes; la fiabilidad también depende de detectar los fallos con antelación, detener los reintentos inútiles y garantizar que una tarea no se marque como exitosa antes de entregar realmente sus resultados. GitHub trabaja en añadir controles para el procesamiento en segundo plano, mejorar el comportamiento durante el inicio de los servicios y reforzar la supervisión y la entrega de los resultados de Copilot code review.
GitHub también registró mejoras en la infraestructura de GitHub Actions: las operaciones de Redis medidas disminuyeron aproximadamente un 28% y el uso relativo de la CPU alrededor de un 30%. Una capa de caché independiente redujo el ancho de banda utilizado por Redis en un 84%, el tiempo medio de respuesta en un 66%, el tiempo de respuesta mediano de la solicitud de inventario principal en un 96% y las solicitudes en espera en un 95%. Las cuestiones pendientes siguen relacionadas con la capacidad de la empresa para completar los trabajos de capacidad y evitar que se repitan fallos de dependencias compartidas en condiciones reales de producción.