La plataforma GitHub ha experimentado en las últimas semanas problemas de fiabilidad alarmantes, con una reducción drástica en su disponibilidad que ha llegado a situarse en torno al 86%, según mediciones externas, una caída respecto al 90% del mes anterior. Esta situación ha culminado en un incidente crítico de integridad de datos y múltiples cortes de servicio que han puesto en jaque a desarrolladores y empresas vinculadas a la plataforma.
Incidente de integridad de datos: la alarma de la comunidad
El 23 de abril, GitHub confirmó un fallo grave relacionado con la funcionalidad de «squash merge» empleada en la gestión de pull requests mediante colas de merge. Cuando un grupo de más de una solicitud se procesaba junto, los commits resultantes en el repositorio contenían errores, llegando incluso a perderse cambios que habían sido revertidos en fusiones posteriores. En total, se vieron afectados 2.092 pull requests, impactando negativamente a compañías como Modal y Zipline, que se vieron obligadas a realizar la recuperación manual del código perdido.
Los equipos afectados tuvieron que navegar en profundidad por el historial de git y aplicar reinstalaciones secuenciales para restaurar las modificaciones, sin soporte efectivo por parte del servicio. Esta incidencia ha generado críticas por la respuesta tibia del equipo ejecutivo de GitHub, quienes, según desarrolladores como Can Duruk de Modal, minimizaron públicamente el alcance de la falla, restando importancia a una violación esencial de la promesa de integridad de datos.
Caídas continuas y aumento inesperado de la carga tecnológica
Además del incidente de integridad, GitHub sufrió un apagón de seis horas el 27 de abril en su interfaz web relacionada con pull requests y problemas, provocado por una sobrecarga y caída del clúster Elasticsearch en su backend. La semana registró además otras interrupciones, entre ellas fallos en GitHub Actions y la aparición incompleta de solicitudes de extracción.
Paralelamente, Wiz, empresa de ciberseguridad, reportó un fallo crítico de seguridad el 28 de abril, que permitía a atacantes comprometer repositorios enteros a través de un simple comando de «git push». Aunque GitHub solucionó el problema rápidamente en su plataforma principal, los servidores GitHub Enterprise permanecen vulnerables si no se actualizan.
More Read
Un referente abandona la plataforma por frustración
La situación llegó a límites insospechados cuando Mitchell Hashimoto, fundador de HashiCorp y creador de Ghostty, anunció públicamente su abandono de GitHub. En su reflexión, Hashimoto detalló que durante semanas casi todos los días registró incidentes que afectaban su productividad, incluso impedimentos de hasta dos horas para realizar revisiones de código por interrupciones en GitHub Actions.
«Este lugar ya no es apto para trabajo serio si bloquea tu actividad durante horas a diario. Quiero estar aquí, pero la plataforma no me deja trabajar. Después de 18 años, debo marcharme. Volveré solo si veo mejoras tangibles, no solo promesas.»
Con esta declaración, polémica y cargada de frustración, Hashimoto confirma la percepción generalizada de que las comunicaciones oficiales y la página de estado de GitHub no reflejan con exactitud el impacto real en usuarios intensivos.
Explicación técnica: el efecto avalancha provocado por agentes de IA
El CTO de GitHub, Vlad Fedorov, atribuyó la crisis de estabilidad a un aumento de la carga generado por agentes de inteligencia artificial ejecutándose sobre la plataforma. Ilustró con gráficas el crecimiento exponencial de peticiones, aunque inicialmente sin escalas claras, que finalmente se ha traducido en un crecimiento aproximado de 3,5 veces en dos años.
More Read
Este incremento progresivo, que pasó desapercibido para la infraestructura actual, ha provocado acumulación de colas de procesamiento, fallos en cachés y sobrecarga en bases de datos, complicando el rendimiento general del servicio. A ello se suma una migración en curso, iniciada en octubre de 2025, desde sus antiguos centros de datos a Microsoft Azure, que pretende ampliar capacidad pero que añade complejidad operativa en medio de la crisis.
Fedorov confirmó que las previsiones iniciales sobre la escalabilidad estaban subestimadas, aumentando las expectativas del crecimiento de capacidad necesaria de 10 a 30 veces en pocos meses, mostrando la dificultad para adaptarse al ritmo impuesto por la adopción masiva de IA.
¿Por qué no sufren otras empresas esta avalancha de problemas?
Mientras GitHub arrastra estas dificultades, otros proveedores y competidores en el entorno de desarrollo y alojamiento de código, como GitLab, Bitbucket, Vercel o Sentry, a pesar de experimentar crecimientos importantes por la integración de IA, mantienen niveles adecuados de fiabilidad. Incluso grandes actores del mundo de la inteligencia artificial, como OpenAI o Anthropic, muestran incidencias muy inferiores en comparación con GitHub.
Esta disparidad lleva a cuestionar si parte de la crisis de GitHub es consecuencia de errores propios. Bajo un paraguas de recursos aparentemente mayores, la plataforma parece haberse visto superada por una combinación de deuda técnica acumulada durante dos décadas, la complejidad organizativa de sus 4.000 trabajadores –1.000 ingenieros– y una planificación insuficiente ante la nuevas demandas del mercado.
Alternativas en auge ante la incertidumbre de GitHub
El malestar y la continuidad de fallos han iniciado un debate entre profesionales para explorar opciones más estables. GitLab y Bitbucket son las alternativas más evidentes, con infraestructuras menos saturadas y una disponibilidad por ahora superior a la de GitHub.
Por otra parte, se plantea la opción del autoalojamiento de repositorios o el uso de forjas locales como Forgejo, un proyecto open source que ofrece características similares a GitHub, pensado para afrontar desde bases más ligeras y controladas el creciente volumen de trabajo impulsado por agentes de IA.
More Read
Se anticipa la aparición próxima de startups especializadas en proporcionar servicios de hospedaje de código con una arquitectura diseñada desde el inicio para soportar escalados de hasta 30 veces o más, cubriendo una necesidad que la plataforma dominante no ha sabido satisfacer aún.
