GitHub Actions y Pages están experimentando disponibilidad degradada

Artículo original ↗ Discusión en Hacker News ↗

Las caídas frecuentes de GitHub Actions y Pages, que duran horas, están llevando a muchos desarrolladores y empresas a cuestionar la fiabilidad de GitHub, especialmente porque estos servicios están en la ruta crítica de CI/CD y despliegues. Los comentaristas especulan sobre causas que van desde la migración a Azure y la carga explosiva impulsada por IA hasta problemas organizativos y culturales en Microsoft, y señalan que las cifras oficiales de uptime y los SLA parecen desconectados de su experiencia. Como resultado, un número notable está explorando o migrando a alternativas como GitLab autohospedado, Forgejo, Woodpecker o configuraciones CI personalizadas para reducir la dependencia del plano de control de GitHub.

Preocupaciones sobre fiabilidad y tiempo de actividad

  • Muchos comentaristas dicen que las caídas de GitHub Actions y Pages se han vuelto frecuentes, con usuarios bromeando con que en la práctica hay “una nueve” o “cero nueves” de disponibilidad.
  • Los rastreadores de uptime de terceros citados muestran ~94–98% de disponibilidad en periodos recientes, frente a las cifras mucho más altas de SLA de GitHub, lo que lleva a acusaciones de que las métricas oficiales son engañosas.
  • La duración de este incidente (alrededor de una jornada laboral completa para algunos) y múltiples incidentes en los últimos meses alimentan la sensación de que la fiabilidad está empeorando, no mejorando.

Impacto en los usuarios y frustración

  • El trabajo está bloqueado: no se ejecuta CI, no se pueden fusionar PR, se retrasan hotfixes y lanzamientos a clientes, y los incidentes de producción son más difíciles de gestionar.
  • Los mensajes de error se describen como engañosos u opacos, por ejemplo, fallos que no indican claramente “no hay runners disponibles”.
  • Algunas empresas sienten que no obtienen estabilidad extra pese a pagar, y que los mecanismos de soporte y créditos de SLA son débiles o “scummy” por diseño.

Causas sospechadas

  • Dos teorías dominantes:
    • Crecimiento masivo de la carga, especialmente por agentes de IA y el uso de Copilot, lo que lleva a 10–14× más commits y más de 4× más minutos de Actions, tensionando la arquitectura.
    • La migración en curso desde la infraestructura antigua de GitHub/AWS a Azure, descrita como inestable y mandatada políticamente.
  • Muchos creen que tanto la carga como la migración, junto con un despliegue agresivo de funciones (especialmente IA/Copilot), están interactuando mal.
  • Algunos sostienen que estos problemas reflejan mala dirección, plazos apresurados y una cultura de ingeniería “performativa”.

Arquitectura de Actions y runners autohospedados

  • A los usuarios les sorprende que también fallen los runners autohospedados, porque el programador central y los webhooks están caídos.
  • Varios critican el diseño: plano de control centralizado como único punto de fallo, flujos de trabajo muy dependientes de YAML y malas estrategias de degradación (sin reducción clara de carga ni prioridad para clientes que pagan).

Alternativas y autohospedaje

  • Fuerte interés en mover CI fuera de GitHub: se mencionan Jenkins autohospedado, GitLab, Forgejo, Gitea, Woodpecker, Buildkite, Argo y varios sistemas CI de nicho.
  • Algunos informan buenas experiencias con GitLab/Forgejo autohospedados + runners (a menudo en un solo servidor), y afirman tener mejor fiabilidad y control.
  • Otros señalan que el bloqueo con un proveedor y los costes de cambio hacen que GitHub siga “ganando” pese a las caídas, especialmente por su UX de PR/revisión y los efectos de red.

Comentario más amplio

  • Los hilos conectan los problemas de GitHub con preocupaciones más amplias: el “slop” de IA, la presión sobre RAM/centros de datos, la calidad de los productos de Microsoft y los riesgos de centralizar la infraestructura crítica de desarrollo en una sola plataforma propietaria.