GitHub muestra dificultades para mantener incluso una disponibilidad del 99.9%

• Las frecuentes caídas del servicio de GitHub han continuado recientemente, y la situación es tal que no solo está lejos del estándar de la industria de “5 nines (99.999%)”, sino que incluso parece difícil alcanzar “3 nines (99.9%)”
• El 9 de febrero, funciones clave como Actions, Pull Request, notificaciones y Copilot sufrieron fallas al mismo tiempo, y algunos servicios registraron demoras de varias horas
• Debido a un problema en la propagación de políticas de Copilot, algunos usuarios experimentaron errores en la visualización de modelos hasta la mañana del 10 de febrero
• Tras el cambio en la estructura de la página de estado de GitHub, se volvió difícil rastrear la disponibilidad de los últimos 90 días, y datos no oficiales incluso muestran momentos con disponibilidad por debajo del 90%
• Aunque el SLA de Enterprise Cloud especifica un 99.9% de uptime, en la práctica no está garantizado para todos los usuarios, por lo que crece la necesidad de contar con estrategias operativas ante el downtime

---

Caída en la disponibilidad de GitHub y frecuentes interrupciones del servicio

• En un contexto donde las fallas frecuentes en servicios en la nube se están volviendo comunes, GitHub también enfrenta problemas de estabilidad
  • Han aparecido expresiones como “es raro que haya un solo día sin incidentes”, e incluso se menciona que no solo está lejos de “5 nines (99.999%)”, sino que hasta “1 nine (90%)” parece difícil de alcanzar
• El 9 de febrero (según UTC), funciones principales de GitHub como Actions, Pull Request, notificaciones y Copilot sufrieron fallas
  • GitHub informó alrededor de las 15:54 que “algunos servicios tenían problemas” y anunció que el retraso en las notificaciones llegaba a unos 50 minutos
  • A las 17:57, la demora se redujo a unos 30 minutos, y a las 19:29 se notificó la normalización del servicio
• La interrupción relacionada con Copilot se prolongó más tiempo
  • Desde las 16:29 del 9 de febrero hasta las 9:57 del 10 de febrero, algunos usuarios experimentaron un problema en la propagación de políticas de Copilot
  • Como resultado, se reportó que los modelos activados recientemente no aparecían para los usuarios
• GitHub cambió la estructura de su página de estado, lo que hizo más difícil seguir la disponibilidad de los últimos 90 días
  • Aunque se siguen ofreciendo detalles, cambió a un formato en el que resulta difícil visualizar la tendencia general del uptime
  • En los datos de una página no oficial de restauración (mrshu.github.io/github-statuses/), se observa que en 2025 hubo momentos en que la disponibilidad cayó por debajo del 90%
• El SLA de Enterprise Cloud de GitHub especifica un 99.9% de uptime, pero no lo garantiza a todos los usuarios
  • En la industria, “5 nines” se considera el estándar ideal, pero se evalúa que algunos proveedores enfrentan la realidad de que incluso mantener el 90% ya es difícil
  • Esta situación sugiere que los clientes deben preparar planes operativos asumiendo la posibilidad de downtime

Contexto relacionado y casos

• GitHub ha atravesado recientemente varias controversias relacionadas con funciones de IA y cambios de políticas
  • La evaluación de un “kill switch” de IA para bloquear código en Pull Request

  • Cancelación del plan de tarifas para runners autohospedados

    • Existe el caso del proyecto del lenguaje Zig, que dejó GitHub citando la política centrada en IA de Microsoft
    • Junto con estos hechos, la caída en la estabilidad del servicio ha contribuido al descontento en la comunidad de desarrolladores

Conclusión

• Las interrupciones recientes de GitHub dejan en evidencia problemas de disponibilidad que dificultan alcanzar incluso “tres nueves” (99.9%)
• A medida que continúa la inestabilidad de funciones clave como Copilot, asegurar la confiabilidad de las plataformas de desarrollo basadas en la nube se vuelve una tarea cada vez más importante
• Se vuelve a enfatizar la necesidad de establecer estrategias ante el downtime

[elbanic]

GitHub es un servicio gratuito, así que esperar alta disponibilidad de por sí ya es...

[cosine20]

¿Dirían lo mismo incluso si KakaoTalk sufriera una caída...?

[malkeu]

Parece que bastaría con hacer git reset --hard.

[master6559]

Si tan solo GitHub no tuviera caídas, así como está ahora estaría bien

[GN⁺]

Opiniones en Hacker News

• El problema de uptime de GitHub claramente es serio, pero me parece exagerado decir que “GitHub entero se cayó” solo porque no todas las funciones se detuvieron al mismo tiempo
  Casi no uso Copilot, así que aunque ese servicio se caiga seguido no me importa mucho
  Lo realmente importante es la estabilidad de funciones clave como Git, el sitio web, la API y Actions

  • De acuerdo. Pero en los últimos 90 días, ningún servicio individual logró un 3x9 (99.9%) de uptime
    Según el Enterprise SLA de GitHub, deberían garantizar al menos 99.9% por servicio, y las cifras reales pueden verse aquí
  • Es cierto que decir “GitHub se cayó” es una exageración, pero en la práctica incluso la API apenas llega a 99.69%, o sea, solo dos nueves
    Copilot está al nivel de un nueve, y lo mismo pasa con servicios centrales como Git y Actions
  • Esta empresa forma parte del portafolio de una corporación global valuada en un billón de dólares
    Una compañía con esos recursos no tiene excusa para descuidar a sus clientes
  • Hoy en día eso de los “5 nines” que mencionan las grandes empresas es casi una ilusión
    En la práctica, hasta responder con error cuenta como “funcionando”
    Casos que realmente logran 99.999%, como en la industria de redes, son raros; la mayoría apenas mantiene la página de estado en verde con trucos de segmentación de datos

• Empecé a preocuparme desde que el CTO de GitHub anunció en 2025 que harían una “migración total a Azure” para mejorar la estabilidad
  Antes la comunidad pedía a gritos que agregaran funciones más rápido, pero ahora lo que más urge es la estabilidad y confiabilidad

  • Aun así, GitHub sigue siendo lento incluso para agregar nuevas funciones
  • Si no dependes solo de plataformas gigantes, también hay alternativas pequeñas y aburridamente estables
  • Yo me uní en esa época, y me parecía increíble poder simplemente compartir mis repos de forma pública
  • En general la estabilidad de toda la industria ha mejorado, pero ahora hay demasiadas dependencias entrelazadas y basta con que falle una para que todo se tambalee
  • Ojalá que cuando hagan la transición completa a Azure no se les olvide otra vez el acceso por IPv6

• GitHub ahora está sufriendo una triple presión: migración a Azure, cambios de infraestructura basados en IA y explosión del tráfico de IA
  En proyectos populares, a los pocos minutos de abrir un issue llegan decenas de PR generados por IA
  Es difícil soportar una carga así, y los “N 9s” antes y después de la IA son niveles de dificultad completamente distintos

  • Exacto. GitHub originalmente no fue diseñado pensando en este tipo de entorno de estampida de agentes de IA

• Si miras la página de estado de GitHub, en realidad está en 90.21%, o sea, al nivel de un nueve
  En el archivo de 2019, antes había entre 1 y 4 incidentes al mes; ahora es casi uno por día

  • La razón por la que esta cifra es mala no es solo el downtime, sino que también incluye degraded performance
  • Aun así, alguien bromeó diciendo que sigue siendo mejor que status.claude.com de Claude

• Mientras GitHub está obsesionado con las funciones de IA, la seguridad de la plataforma se está desmoronando
  Recientemente Aqua Security fue atacada y varios repos fueron infectados; fue un caso de explotación de la vulnerabilidad de referencias mutables en GitHub Actions
  GitHub conoce este problema y aun así no lo ha arreglado

  • Como solución temporal, conviene fijar (pin) las versiones de Actions con un hash
    Ejemplo: uses: actions/checkout@11bd7190...
    Para automatizarlo, consulta mheap/pin-github-action
  • Creo que CI/CD se ha enredado demasiado por la complejidad basada en YAML
    Antes desplegábamos con Jenkins y las pruebas simples se resolvían con scripts, pero ahora todo se volvió un infierno de YAML distribuido
  • La seguridad de GHA es tan grave que hay quienes dicen que “tiene más agujeros que un queso suizo”
  • También existe una discusión de la comunidad donde llevan años dejando pasar este problema

• Ese 90% de uptime incluye todos los servicios, así que la experiencia real puede sentirse distinta
  Pero incluso el 96.47% de Copilot sigue siendo apenas un nueve
  GitHub recomienda usar “todas las funciones juntas”, pero mientras más lo haces, la confiabilidad cae de forma drástica

  • Además, los casos de “funciona, pero lento” no entran en la estadística
    Por ejemplo, abrir un diff simple de un PR puede tardar más de 30 segundos
  • Algunos incidentes incluso se reportan tarde de forma oficial
    Hubo casos en los que CI/CD, git y las funciones de PR se detuvieron al mismo tiempo
  • Comparado con los datos de 2019, ahora está más de 10 veces peor
  • 96% es una cifra realmente terrible

• Habiendo operado GitHub Enterprise Server directamente, estos problemas no me sorprenden
  No cumple requisitos básicos de alta disponibilidad como sin soporte active-active, sin upgrades sin downtime y sin rollback
  Si aparece un bug, no hay otra salida más que restaurar un backup, y en el proceso se produce pérdida de datos
  Que vendan un producto así a clientes premium es evidencia de una indiferencia total por la disponibilidad

  • En nuestra empresa al final también abandonamos GHES y migramos a GHEC

• Microsoft tiene talento para arruinar productos buenos
  Skype es el ejemplo clásico, y también pasa con Windows, Notepad y Explorer
  La confusión de branding que va de Office → Office 365 → Microsoft 365 → Copilot 365 también es bastante seria

  • Parece que no falta mucho para que llegue “GitHub for Business”

• En nuestra empresa corremos escaneos de seguridad con GitHub Actions en cada PR
  Si GitHub se cae, también se detienen las puertas de seguridad, y los desarrolladores terminan haciendo merge sin validación
  Así es como entra código vulnerable, y aun así GitHub sigue destinando su personal solo a Copilot

  • También hubo quien preguntó si existe algún caso público sobre esto

• Ignorar IPv6 simboliza la negligencia técnica de GitHub
  El problema mayor es por qué aun en este estado sigue aprobando auditorías de seguridad
  Si miras la documentación de seguridad de GitHub, parece algo meramente formal

  • La calidad de las auditorías también es tan mala como la arquitectura