- Se reportaron degradación de rendimiento y errores en servicios clave de GitHub como Actions, Issues y operaciones de Git
- El alcance del impacto se extendió a Webhooks, Pull Requests, Packages, Pages y Codespaces
- GitHub aplicó medidas de mitigación y confirmó una recuperación gradual; posteriormente, todos los servicios volvieron a la normalidad
- La interrupción también afectó algunos servicios como Dependabot y Copilot, pero finalmente regresaron a estado operativo normal
- GitHub publicará más adelante un análisis de causa raíz (RCA) y agradeció a los usuarios por su paciencia y colaboración
Resumen de la interrupción
- GitHub anunció que estaba investigando reportes de degradación de rendimiento en Actions, Git Operations e Issues
- En la etapa inicial se observaron respuestas lentas y solicitudes fallidas, además de trabajos de Actions retrasados
- La interrupción fue reportada por primera vez el 9 de febrero de 2026 a las 19:01 UTC
Servicios afectados
- Los componentes afectados fueron Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages y Codespaces
- Más adelante también se confirmaron problemas en Dependabot y Copilot
- Cada servicio fue marcado con estado de “degraded performance”
Respuesta y proceso de recuperación
- GitHub informó que observó señales de recuperación tras aplicar medidas de mitigación
- La recuperación gradual avanzó después de las 19:29 UTC
- A las 19:54 UTC, varios servicios ya se habían recuperado, aunque algunos seguían en investigación
- A las 20:08 UTC se informó que “todos los servicios estaban procesando normalmente”
- A las 20:09 UTC el estado cambió a Resolved
Estado final y medidas posteriores
- GitHub indicó que todos los servicios habían vuelto a estado operativo normal
- Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests y Webhooks quedaron normalizados
- El análisis de causa raíz (Root Cause Analysis) se compartirá cuando esté listo
- La empresa expresó su agradecimiento por la paciencia y comprensión de los usuarios
Resumen
- Esta interrupción afectó gran parte del flujo de trabajo central de desarrollo en GitHub
- Tras completarse la recuperación, se publicará el RCA, y se esperan mejoras para prevenir incidentes similares en el futuro
- El hecho de que se reportara otra interrupción el mismo día volvió a poner en relieve la importancia de la gestión de la estabilidad
1 comentarios
Comentarios de Hacker News
Debido a la degradación parcial continua de GitHub, están considerando mover toda la empresa a otro proveedor
Funciones que antes andaban bien ahora son lentas, y Actions tampoco se ejecuta a tiempo
Copilot está bien, pero al final, si el git forge no funciona correctamente, no queda otra que irse
Abrir un diff simple de un PR puede tardar más de 15 segundos, y la UI se queda como congelada una y otra vez
Sorprende que esta degradación anormal del rendimiento se esté aceptando como algo normal
Al final, la esencia de git es que incluso puedas correr el pipeline de CI en local
Yo uso GH solo para sincronizar
Si ves publicaciones antiguas, ya estaban chocando con los límites de escalado de su base de datos SQL
Se parece al caso de escalado de Postgres de OpenAI, pero da la impresión de que GitHub no ha respondido igual de bien
Las caídas frecuentes de GitHub más bien han servido para revisar la resiliencia del pipeline de despliegue
La mayoría de los equipos dependen por completo de GitHub, así que cuando falla, se detienen los despliegues
Por eso han probado alternativas como estas
La página oficial de estado siempre se actualiza tarde, así que ahora la tratan solo como información “eventually consistent”
Puede que GitHub esté sufriendo la carga causada por la explosión de workflows de desarrollo automatizados
Los commits en repos personales se han disparado, pero casi nadie se convierte a plan de pago
Creen que en 2019 perdieron una oportunidad de monetización al hacer gratuitos los repos privados
Y además falta sentido de responsabilidad frente al downtime
Afirman que GitLab es la alternativa
GitHub ahora está enfocado solo en una estrategia centrada en IA, y la plataforma en sí quedó en segundo plano
La adopción de Copilot también es baja, y las empresas usan más Claude
Si Microsoft cambia de dirección, la situación empeorará todavía más
Saca funciones a medio terminar y además va lento
Las ventajas de su modelo open-core ya no se sienten tanto
Evolucionó de Dev → DevOps → DevSecOps → AI DevSecOps, pero
en cada etapa la calidad de terminación ha sido baja, y además resulta incómodo que el upgrade de licencia sea obligatorio
Consideran que el verdadero problema es unir CI/CD y el hosting de código en una sola estructura
Incluso si funcionara perfectamente, al final no se puede evitar el lock-in de proveedor
Antes debería bastar con cambiar el remote, pero ahora todo quedó entrelazado con PRs, wiki y demás
Ahora las caídas de GitHub ya no se sienten como un simple problema de SaaS, sino como una caída a nivel nube
Por eso muchos equipos están migrando a GitLab/Gitea autohospedado
En una gran empresa usaban GitLab Enterprise on-premises por motivos de seguridad,
y para proyectos personales operan con Forgejo
Git, issues, boards y wiki funcionan bien, y las scoped labels son gratis
Hay una página que visualiza el historial de múltiples fallas de GitHub
Se puede revisar en mrshu.github.io/github-statuses
También hay un comentario en tono de broma: “equipo de GitHub, no pasa nada si se lo toman con calma”
Quieren dejar GitHub, pero necesitan CI estable y un registro de contenedores
Si hubiera una solución que “simplemente funcione”, estarían dispuestos a pagar por ella
Es adecuado para cargas grandes, pero el costo inicial es alto
La gestión de permisos del registro es un poco compleja, pero la integración general está bien lograda
Creen que habría que volver a herramientas de propósito único, como en la filosofía Unix
Sería interesante ver un gráfico de la correlación entre la tasa de adopción de IA y la frecuencia de fallas