Qué revela la disponibilidad GitHub en el informe de septiembre
La disponibilidad GitHub volvió al centro del debate después de varios incidentes que afectaron servicios y herramientas de desarrollo durante agosto y septiembre de 2026. El informe más reciente reúne avances de infraestructura, pero también admite que la migración regional tuvo que pausarse y que una operación planificada interrumpió clientes.
Leer los porcentajes junto a esas fallas permite distinguir mejoras de capacidad de garantías de continuidad. Los datos describen trabajo en marcha, no una promesa de que los próximos incidentes serán menores ni de que todos los componentes respondan igual.
Disponibilidad GitHub y el avance desigual hacia Azure
GitHub indicó que la actualización cubre dos meses: no publicó otra edición en septiembre, mientras sus comunicaciones abordaban el corte del 17 de agosto. La disponibilidad GitHub al 7 de octubre refleja una migración importante, aunque incompleta, de servicios centrales a Azure.
De 160 servicios de producción, 120 estaban desplegados en Central US; también se trasladaron 13 de las 51 bases de datos MySQL primarias. El avance no significa que la migración terminara ni determina por sí solo cuánto riesgo conserva cada dependencia.
Azure gestionaba el 65,4 % de las lecturas de la aplicación central, el 48,3 % del tráfico Git y el 80,2 % del procesamiento en streaming. Son porcentajes de cargas distintas; sumarlos sería engañoso porque sus denominadores no coinciden.
El 11 de septiembre se detuvieron despliegues en Central US y aumentos de tráfico por capacidad desigual entre zonas. La disponibilidad GitHub quedó así sujeta a una pausa preventiva; los incrementos permanentes se reanudaron el día 18, tras obtener margen temporal.
GitHub no alcanzó su meta acelerada del 30 de septiembre para trasladar allí todos los servicios de producción. Ahora busca desbloquear la capacidad disponible antes de terminar octubre. La fecha es una meta de ingeniería, no prueba de resiliencia regional completa.
Durante una conmutación planificada de bases de datos, un proceso de emergencia desconectó copias de Central US e interrumpió clientes. GitHub deshabilitó ese proceso durante transferencias planificadas y mejora la recuperación: también fallan los mecanismos de protección.
Dos incidentes revelan fallas distintas de control
La disponibilidad GitHub se interrumpió el 13 de septiembre cuando una tarea de limpieza elevó la carga de una base de datos compartida y agotó las conexiones del servidor principal. La protección vigilaba el retraso de réplicas, no la presión sobre ese nodo.
Sin tiempos de espera breves, algunas solicitudes aguardaron la base saturada; un ciclo de reintentos siguió enviando escrituras fallidas. Ambas condiciones prolongaron el problema, que duró una hora y 28 minutos, según la cronología oficial.
GitHub redujo carga y pausó la limpieza, tras lo cual bajaron los errores. Anunció controles que ajustan el procesamiento a la capacidad disponible, frenan reintentos innecesarios y limitan llamadas lentas; también mejorará el arranque ante conexiones inestables.
El 28 de septiembre, Copilot dejó de entregar revisiones de código durante 52 minutos. El servicio devuelve una copia limitada y otra completa; solo esta última contiene comentarios. Un cambio hizo que algunos clientes recibieran únicamente la versión limitada.
La aplicación esperaba la copia completa y no podía construir la revisión, aunque marcaba la tarea como exitosa. Faltaban alertas sobre resultados ausentes; el equipo revirtió el cambio y reforzará entrega, recuperación y monitorización.
Los incidentes muestran fallas distintas en la disponibilidad GitHub: presión de base de datos y reintentos, frente a una entrega incompleta reportada como exitosa. La diferencia permite valorar si los controles anunciados corrigen causas o solo síntomas.
Qué métricas muestran progreso y qué queda por probar
Fuera de Azure, GitHub trasladó 24 tablas de autenticación desde su base de datos compartida más antigua. Calcula que retiró cerca de un millón de consultas por segundo de las réplicas, aliviando una dependencia central.
En Issues y Pull Requests eliminó unos 980 millones de filas innecesarias del historial de edición y recuperó capacidad estimada en 1,8 terabytes. Los interbloqueos semanales bajaron cerca del 77 % frente al máximo de junio; continúa la limpieza automática.
GitHub informó que la mitad del tráfico de Pull Requests muestreado puede continuar con funciones limitadas si falla una dependencia. Algunas lecturas siguieron disponibles durante un incidente, pero eso no garantiza que todas las escrituras o usuarios queden protegidos.
El enrutamiento de bases de datos puede sumar capacidad durante picos: un grupo pasó de 14 a 19 instancias el 23 de septiembre. En Actions, los cambios redujeron operaciones Redis cerca del 28 % y CPU relativa alrededor del 30 %.
Otra caché redujo el ancho de banda Redis un 84 %, la latencia media un 66 %, la mediana de la solicitud de inventario un 96 % y las peticiones en cola un 95 %. Son medidas de componentes, no una cifra de disponibilidad GitHub.
La disponibilidad GitHub depende de límites de carga, timeouts, reintentos, entregas verificables y capacidad regional. Las métricas muestran avances; los cortes y la pausa de capacidad recuerdan que los controles aún deben responder bien durante fallas reales y cambios planificados.
Implementación de Agentes de IA & Automatización de Procesos
Lleve la productividad de su empresa al siguiente nivel. Diseñamos e integramos agentes inteligentes a la medida para automatizar su flujo de ventas, atención al cliente y operaciones repetitivas de forma 100% segura.
Preguntas frecuentes sobre disponibilidad GitHub
1. ¿El informe confirma que GitHub migró toda su infraestructura a Azure?
No. Al 7 de octubre, GitHub informaba 120 de 160 servicios de producción y 13 de 51 bases de datos MySQL primarias en Central US. También señaló que no cumplió su meta de septiembre y que seguía trabajando para desbloquear capacidad regional antes de terminar octubre.
2. ¿Qué provocó la interrupción del 13 de septiembre?
Un proceso de limpieza aumentó la carga de una base de datos compartida hasta agotar las conexiones del servidor principal. La protección observaba el retraso de réplicas, no esa carga; las llamadas sin timeout y los reintentos prolongaron la saturación antes de que GitHub pausara el proceso.
3. ¿Las mejoras anunciadas garantizan que no habrá nuevos cortes?
No. Menos consultas, menor latencia o más capacidad pueden reducir riesgos en componentes determinados, pero no garantizan continuidad total. El informe reconoce incidentes recientes, una pausa de capacidad y trabajo pendiente; conviene evaluar cada servicio, sus dependencias y la respuesta observada durante fallas.
Consulta el reporte oficial de disponibilidad, sigue el portal de noticias tecnológicas y conoce Gazu Technology. La conclusión es técnica: las métricas muestran progreso, pero la resiliencia exige controles que detecten fallas y limiten su impacto en producción.
