GitHub pide disculpas por su disponibilidad y promete priorizar la fiabilidad ante el auge del desarrollo con AI
La Disponibilidad de GitHub vuelve a estar en el centro del debate en la industria del software: la plataforma de Microsoft publicó un comunicado de disculpa y un plan de acción tras una secuencia de incidentes que impactaron en flujos de trabajo críticos como Pull Requests, Merge Queue, búsqueda y GitHub Actions. El mensaje, firmado por el CTO Vlad Fedorov, reconoce el “dolor” de los desarrolladores y fija un cambio de prioridades: primero disponibilidad, después capacidad y, por último, nuevas funciones.
El contexto no es menor: las quejas han escalado a medida que proyectos relevantes cuestionan la idoneidad de GitHub como “source of truth” para trabajo serio. Entre los detonantes recientes, el cofundador de HashiCorp, Mitchell Hashimoto, anunció públicamente su intención de mover el proyecto Ghostty fuera de GitHub, citando interrupciones frecuentes que afectan tareas diarias como la revisión de PRs y la ejecución de pipelines.
Disponibilidad de GitHub: incidentes recientes y fallos visibles
En su actualización, GitHub enumeró varios eventos concretos. El 23 de abril, un bug en Merge Queue provocó que grupos de merge con más de un Pull Request generasen commits incorrectos. Según la propia compañía, en los casos afectados “cambios de PRs previamente fusionados y commits anteriores fueron revertidos inadvertidamente por merges posteriores”, un tipo de fallo especialmente sensible porque no solo degrada el servicio, sino que puede alterar el historial efectivo que llega a la rama principal.
Días después, el 27 de abril, partes de la interfaz dependientes del sistema de búsqueda dejaron de mostrar resultados tras sobrecarga del clúster de Elasticsearch. GitHub apunta como hipótesis a un posible ataque tipo botnet y afirma que sigue trabajando en el análisis de causa raíz. Más detalles y el estado del servicio se pueden seguir en el panel oficial de la compañía: GitHub Status.
AI y agentic workflows: el factor que GitHub señala como acelerador
GitHub atribuye parte del deterioro de la Disponibilidad de GitHub a un cambio rápido en cómo se construye software. En concreto, sostiene que desde la segunda mitad de diciembre de 2025 se aceleraron los agentic development workflows, es decir, flujos donde agentes con AI incrementan el volumen de operaciones (consultas, búsquedas, ejecuciones, automatizaciones y actividad sobre repositorios) a una velocidad superior a la prevista por el capacity planning tradicional.
La compañía reconoce además que su previsión inicial se quedó corta: planificó un aumento de capacidad de 10x, con trabajos iniciados en octubre de 2025, pero para febrero de 2026 concluyó que necesitaba aproximadamente 30x. Ese desfase explica, en parte, por qué se han acumulado degradaciones en componentes “calientes” del producto, especialmente aquellos que soportan interacción en tiempo real (UI, search, colas de merge) y automatización (Actions).
Qué promete cambiar GitHub
En el comunicado, GitHub define una hoja de ruta operativa centrada en ingeniería de fiabilidad: reducir trabajo no esencial, mejorar caching, aislar servicios críticos, eliminar single points of failure y mover rutas sensibles al rendimiento hacia sistemas diseñados para estas cargas. El objetivo implícito es mejorar resiliencia y reducir el blast radius cuando un subsistema (por ejemplo, search) sufre saturación.
GitHub también rechaza que la migración a Azure sea la causa principal de la degradación. Al contrario, sostiene que la transición ha ayudado a desplegar más compute con rapidez para responder a picos de demanda. La posición de la compañía encaja con su narrativa de que el problema principal es el cambio de patrón de consumo, no el proveedor cloud en sí.
Por qué la Disponibilidad de GitHub importa a empresas y equipos DevOps
La Disponibilidad de GitHub no se limita a la experiencia de “subir código”: es un componente transversal en CI/CD, control de cambios, auditoría de PRs, revisiones de seguridad, gestión de releases y continuidad operativa. Cuando se degrada, el coste se propaga: se frenan despliegues, se bloquean revisiones, se retrasan hotfixes y se incrementa el riesgo de trabajo duplicado o merges conflictivos. Además, incidentes como el de Merge Queue añaden una capa más delicada: el impacto potencial sobre la integridad de lo que se integra en main.
En paralelo, el momento es especialmente sensible porque la industria está reconfigurando su stack de desarrollo alrededor de AI, lo que eleva la dependencia de plataformas centrales. En ese entorno, la tolerancia a degradaciones recurrentes baja y crece la presión por alternativas (auto-hosting, mirrors, o plataformas competidoras) para mitigar riesgo.
GitHub ha publicado su postura oficial en su blog corporativo, donde detalla su lectura del problema y prioridades: GitHub Blog (actualización de disponibilidad).
Aun así, el reto clave no es el comunicado, sino la ejecución: recuperar confianza exige evidencias sostenidas de mejora en SLOs, reducción de incidentes de alto impacto y mayor transparencia técnica en postmortems. Por ahora, GitHub admite el problema y promete cambios, pero la Disponibilidad de GitHub seguirá bajo escrutinio mientras los equipos dependan de la plataforma para entregar software.
