GitHub cayó otra vez: 3 caídas en 2 meses y los devs ya huyen

Si hoy intentaste hacer git push y GitHub te contestó con un "Internal Server Error", no estabas solo. A las 15:06 UTC la plataforma de Microsoft empezó a fallar, y en cuestión de minutos millones de desarrolladores se quedaron sin poder subir código, sin poder abrir pull requests y sin CI.

Otra vez. Y esta vez la paciencia de la comunidad se agotó.

Lo que pasó, minuto a minuto

GitHub declaró el incidente a las 15:14 UTC con impacto "critical". La ventana real de caída fue de 15:06 a 15:16 UTC, pero el desastre se sintió mayor: Git Operations, Pull Requests y Actions caídos, con Issues y Webhooks degradados.

El servicio se recuperó por completo a las 16:25 UTC — casi 70 minutos de outage. Miles de usuarios reportaron el fallo en Downdetector, y en Hacker News la historia llegó a portada con 219 puntos y 170 comentarios.

Los testimonios no daban crédito: "Es la primera vez que veo un git push en GitHub devolver un Internal Server Error", escribió un usuario. Otro, más seco: "¿Un PR? No puedo ni hacer push jaja".

Tercera vez en dos meses: ya no es un accidente

Aquí viene lo incómodo. El 17 de agosto GitHub se cayó durante horas con Actions, APIs, PRs y Copilot fuera de servicio — una caída tan grande que su blog todavía publica "el análisis del outage del 17 de agosto". El 26 de agosto volvió a caer, solo Actions. Y hoy, 7 de octubre, la tercera.

En los comentarios de HN la ironía dolía: "¿No habíamos estado sin outages unas semanas? Hubo uno el lunes, como siempre". Otro dev resumió el mood general: "Pensé que era raro que lleváramos semanas sin uno… y aquí está".

Dos meses, tres caídas graves. Esto ya no es "mala suerte": es el nuevo normal de una plataforma que sostiene gran parte del código del planeta.

La huida ya empezó

Lo mejor del hilo no fue la queja, fue la receta de escape. Un desarrollador contó que corre Forgejo en un contenedor con backups a S3 privado: "30 minutos de configuración y después seguí con mi vida", junto con una donación al equipo de Forgejo.

Otros confirmaron que Gitea, Forgejo, GitLab CE y hasta SSH tradicional siguieron perfectamente estables mientras GitHub se desmoronaba. Y no faltó el comentario que ya es un clásico: "Azure es la razón por la que GitHub se cae tan seguido".

Tu CI no debería depender de una sola empresa

Ángulo que le importa a cualquier equipo en LATAM con releases apretados: si tu pipeline de despliegue vive 100% en GitHub Actions, hoy tu release se paró sin aviso y sin que tú hicieras nada mal.

Tres medidas que evitan el susto: ten un mirror en Gitea/Forgejo (un git push --mirror automático cada hora basta), no ates tu CI a un solo proveedor, y guarda los tags y releases localmente — un git bundle te salva el fin de semana.

Veredicto

GitHub sigue siendo el mejor lugar para alojar código, pero hoy dejó de ser el lugar seguro para alojar código. Hay diferencia. Microsoft compró comodidad y una sola factura, y a cambio aceptamos que cuando GitHub se cae, el mundo entero deja de programar.

¿Es hora de autoalojar, o aguantas mientras no sea tu release el que se pierda?

Comparte esto con ese compañero que dice "GitHub nunca se cae" 😏