Incidente con Github.com [resuelto]

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

Los cortes repetidos y de varias horas en GitHub —que afectan a pull requests, issues, Actions y la interfaz web mientras la página oficial de estado va con retraso o permanece “all green”— están llevando a muchos desarrolladores a cuestionar su fiabilidad como infraestructura crítica. Los comentaristas debaten las causas, desde la migración de Microsoft a Azure y la generación de código impulsada por IA hasta la falta de inversión en operaciones básicas, y discuten si ya van tarde los límites de tasa o precios más altos para el uso intensivo (a menudo basado en LLM). Un número creciente de equipos informa que está migrando activamente o planea migrar a alternativas como GitLab autoalojado, Gitea/Forgejo o forjas federadas más nuevas, lo que subraya preocupaciones más amplias sobre la centralización, el bloqueo con un proveedor y la fragilidad de una plataforma dominante de alojamiento de código.

Síntomas del corte e impacto

  • Muchos usuarios informan que GitHub es inutilizable: páginas de error con unicornio, errores 500, 404, “cannot retrieve latest commit”, el estado de merge de los PR no carga, Actions falla y los webhooks no se activan.
  • Las operaciones básicas de git a menudo siguen funcionando (clone, push), y a veces la CLI (gh) o la API funcionan donde la interfaz web no lo hace, pero las canalizaciones de CI/CD y los flujos de trabajo basados en la web quedan bloqueados.
  • El corte dura varias horas, y algunos usuarios señalan incidentes similares apenas unos días antes; algunos lo toman como un descanso forzado, otros como una interrupción grave del negocio.

Página de estado y gestión del incidente

  • La página oficial de estado muestra inicialmente “todo en verde”, luego más tarde “degraded performance” y una “~20% error rate”.
  • Muchos sienten que esto subestima la situación: para ellos, en la práctica está al 100% caído para PRs/issues.
  • Varios señalan que los incidentes de “degraded performance” no parecen reflejarse en las estadísticas de disponibilidad; también faltan cortes antiguos o se han rellenado después como 100% de uptime, lo que erosiona la confianza.

Causas sospechadas

  • GitHub/Microsoft atribuyen problemas recientes de disponibilidad al crecimiento masivo, especialmente al uso de código y Actions impulsado por IA/LLM (aumento de uno o más órdenes de magnitud en commits y minutos de CI).
  • Algunos comentaristas coinciden en que la escala es realmente difícil; otros argumentan:
    • Los cortes son anteriores al auge de la IA y se intensificaron después de la adquisición por Microsoft y la migración a Azure.
    • Otros servicios a escala web gestionan una fiabilidad mayor.
    • El exceso de funciones y los cambios “vibe-coded”/asistidos por IA pueden estar perjudicando la robustez.

Negocio, fiabilidad y SLAs

  • Muchas organizaciones ahora tratan GitHub (incluido Actions) como infraestructura crítica; los cortes bloquean hotfixes, lanzamientos e ingresos.
  • Algunos sostienen que los usuarios deberían tener planes de contingencia, réplicas y no tratar un SaaS de terceros como un único punto de fallo; otros responden que GitHub se comercializa explícitamente como infraestructura empresarial fiable con un SLA.
  • Existe tensión entre “no te enfades, sal a pasear” y “pagamos por esto; la frustración es legítima”.

Alternativas y migración

  • Se mencionan con frecuencia movimientos hacia:
    • Forjas autoalojadas (GitLab, Gitea, Forgejo) más CI autoalojada (Jenkins, Woodpecker, Buildkite, etc.).
    • Otras forjas alojadas (GitLab.com, Codeberg, opciones federadas más recientes).
  • Se discuten los compromisos:
    • Los efectos de red y la visibilidad social mantienen a la gente en GitHub.
    • Algunos ven el autoalojamiento como barato y fiable; otros, como una carga operativa.
    • La migración de CI/Actions y la pérdida de integraciones son las partes más difíciles.

Centralización, comunidad y precios

  • Reflexión más amplia de que la centralización de GitHub convirtió el git distribuido en un único punto de fallo y en una red social para desarrolladores.
  • Algunos celebran una “diáspora” de vuelta a herramientas más distribuidas o federadas; otros temen la pérdida de descubribilidad y de normas compartidas.
  • Muchos sugieren que GitHub debería limitar el tráfico pesado/LLM o cobrar más agresivamente por él, y priorizar a los usuarios de pago y humanos, pero señalan que los incentivos empresariales pueden desincentivarlo.