GitHub: interrupción en las operaciones de Git

 (githubstatus.com)
3 puntos por GN⁺ 2025-11-20 | 1 comentarios | Compartir por WhatsApp
  • El 18 de noviembre de 2025 (UTC), en GitHub se produjo una falla en todas las operaciones de Git, lo que interrumpió los clientes SSH y HTTP y el acceso a archivos sin procesar
  • Se confirmó que la causa del problema fue la expiración de un certificado TLS usado para la comunicación entre servicios internos
  • GitHub reemplazó el certificado vencido y reinició los servicios afectados, completando la recuperación total
  • Después de esto, está reforzando las alertas de monitoreo por expiración de certificados y avanzando en la transición a la automatización para eliminar los certificados gestionados manualmente
  • Esta interrupción afectó a Git Operations y Codespaces de GitHub, y tras la recuperación todos los servicios volvieron a un estado normal

Informe de interrupción en las operaciones de Git

  • Entre las 20:30 y las 21:34 UTC del 18 de noviembre de 2025, en GitHub se produjo una falla en todas las operaciones de Git

    • Se vieron afectados tanto las interacciones de clientes Git por SSH y HTTP como el acceso a archivos sin procesar
    • Los productos que dependen de las operaciones de Git también sufrieron la misma interrupción

  • Se confirmó que la causa fue un certificado TLS vencido usado para la comunicación entre servicios internos

    • GitHub reemplazó el certificado y reinició los servicios afectados para resolver el problema
    • Tras reiniciar los servicios, se logró la recuperación completa

  • Para evitar el mismo problema en el futuro, GitHub está fortaleciendo el sistema de alertas por expiración de certificados

    • También está realizando revisiones de monitoreo y automatización sobre otros certificados en áreas relacionadas
    • Está acelerando la eliminación de los certificados aún gestionados manualmente y la implementación de un sistema automatizado de comunicación entre servicios

Desarrollo de la interrupción y etapas de recuperación

  • 20:39 UTC: se reportó degradación de disponibilidad en las operaciones de Git y en Codespaces
  • 20:52 UTC: se confirmó la falla de algunas operaciones de Git por HTTP
  • 21:11 UTC: se confirmó la falla de todas las operaciones de Git
  • 21:25 UTC: continuaba la degradación de disponibilidad en Codespaces
  • 21:27 UTC: causa identificada, en curso el trabajo de corrección
  • 21:36 UTC: comenzó la recuperación parcial tras desplegar la corrección
  • 21:55 UTC: todos los servicios normalizados, recuperación de Codespaces completada
  • 21:56 UTC: se confirmó la operación normal de Git
  • 21:59 UTC: incidente cerrado y reporte publicado

Servicios afectados

  • Git Operations
    • Operaciones de Git en general basadas en SSH y HTTP
  • Codespaces
    • Se produjo una degradación temporal de disponibilidad

Acciones de seguimiento

  • Refuerzo del monitoreo de expiración de certificados y de la automatización
    • Establecimiento de un sistema de alertas previas al vencimiento
    • Revisión del proceso de renovación automática de todos los certificados internos
  • Ampliación de la automatización de seguridad y operaciones
    • Eliminación de la gestión manual de certificados
    • Implementación de comunicación automatizada entre servicios alineada con las prácticas modernas de seguridad

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-11-20
Comentarios en Hacker News

  • Me preocupa que las caídas de sistemas de software importantes estén ocurriendo demasiado seguido
    El año pasado solo hubo cuatro incidentes que afectaron el trabajo, pero este trimestre ya vamos por el cuarto
    Se siente como si la resiliencia del software de red estuviera desapareciendo poco a poco
    Nuestro equipo usa una arquitectura monolítica, pero tiene muchas dependencias como Redis, S3 y servicios de integración externos
    Por eso documentamos las condiciones de fallo, reforzamos las pruebas y la automatización de despliegues, y simplificamos migrando de la nube a VPS
    Como resultado, el sistema se volvió mucho más estable y predecible
    Sin ese trabajo aburrido pero esencial, la complejidad solo habría aumentado y nos habría vuelto más vulnerables
    Las caídas recientes que vivimos fueron las de AWS us-east-1, Azure Front Door, Cloudflare y GitHub

    • Al final creo que el problema es el dinero
      Los clientes no quieren gastar en resiliencia ni en infraestructura redundante
      Desde 2008 he trabajado en más de diez proyectos, pero en la mayoría la actitud fue de “dejémoslo a la suerte”
    • De acuerdo. Los recortes de costos están llevando al resultado de “olvidarnos de cómo construir sistemas que aguanten incluso cuando hay una caída”
    • Si quiero ser deliberadamente provocador, diría que el aumento en el uso de LLM también está contribuyendo a este fenómeno

  • Git es un sistema de control de versiones distribuido, así que se puede seguir trabajando aunque GitHub no esté disponible
    GitHub es solo un hub conveniente

    • Eso sí, si una empresa depende por completo de GitHub Actions, entonces queda totalmente bloqueada como ahora
    • Es como: “Esta escalera mecánica se convirtió temporalmente en escaleras. Disculpe las molestias”
    • La esencia del problema es que GitHub se cayó, no que git se haya caído
    • Sin GitHub se pierde la función de hub de colaboración con otras personas
    • La razón por la que estamos en Hacker News ahora es porque no podemos trabajar

  • La falta de confiabilidad de GitHub se siente grave
    Para quienes dependen de CI/CD, es algo crítico
    Internamente parece verse solo como “se rompió el CI/CD de nuestro equipo”, y falta la perspectiva de “se detuvo la mitad del mundo”
    Esa cultura de silos y la actitud de “no es nuestro problema” terminan degradando la confiabilidad
    Además, gracias a su posición monopólica, los clientes tampoco tienen muchas opciones más que aguantar
    Es la misma actitud de “igual no te puedes ir a otro lado” que ya vi antes en Verio y Verisign

  • Me pregunto si las caídas de cloud/SaaS realmente están ocurriendo más seguido últimamente
    No sé si solo se están reportando más o si de verdad aumentó la frecuencia
    ¿Será por recortes de presupuesto, despidos, adopción de IA o crecimiento excesivo?

    • Microsoft parece creer que todo se resolverá si mueve GitHub a Azure
    • Desde la perspectiva de alguien que lo ha usado por mucho tiempo, sí se siente claramente un aumento en la frecuencia de fallas
      Antes era una o dos veces al año, pero ahora es casi cada mes, y últimamente hasta cada semana
    • Alguien dijo durante la caída de Cloudflare que la “cultura de programar con IA” está empeorando este tipo de problemas
      Pequeños fragmentos de código generados por IA podrían provocar caídas en efecto dominó
    • Como sugiere un artículo de Techrights,
      creo que los despidos masivos han afectado la confiabilidad
    • Por el FOMO provocado por la IA, los cronogramas de los proyectos se volvieron más apretados,
      y al final parece que se ignora ese último 10% del trabajo de estabilidad

  • Como no podía hacer push, al principio pensé que el problema era mío
    Simplemente decidí rendirme hoy y volver a intentarlo mañana

    • La autenticación funcionaba, pero el push no, y de verdad fue una experiencia para arrancarse el pelo
    • Ni agregando una nueva clave SSH sirvió. Al principio solo salían errores raros y al final apareció el mensaje “upstream unhealthy”
    • Yo también estuve a punto de reconfigurar todo desde cero

  • Hoy no quería trabajar, y después de Cloudflare ahora también se cayó GitHub, así que parece una señal para descansar

    • El problema es la dependencia tecnológica centralizada en EE. UU.
      Hace falta más soberanía tecnológica y descentralización

  • De todos los servicios que he usado en los últimos 5 años, GitHub fue el más inestable
    Me pregunto si GitLab será mejor. A estas alturas mi confianza en GitHub es casi cero

    • En nuestra empresa usamos GitLab autohospedado, pero el servidor Gitaly se cae seguido
      Supongo que es por nuestro entorno de monorrepo grande, pero claramente hay problemas de escalabilidad
    • GitLab tiene muchas funciones, pero la integración es desordenada y le falta pulido
      Aun así, tener repositorio, CI/CD, issues y wiki en un solo lugar es una ventaja
    • Uso tanto GitHub.com como GitLab autohospedado,
      y GitHub es vulnerable a las caídas de la nube, mientras que GitLab sufre frecuentes interrupciones en las actualizaciones automáticas
      Cada uno tiene sus pros y contras
    • El problema de GitLab es que es lento y pesado
      Carga varios MB de JS, así que en redes lentas la página casi ni abre
    • Si lo tienes on-premise, puedes asegurar tanta estabilidad como quieras

  • En una emergencia se pueden editar archivos directamente desde la UI web de GitHub
    Pero actions/checkout@v4 de GH Actions ahora mismo no funciona por el problema con git

    • En realidad, se puede hacer git push/pull con cualquier host accesible por SSH
    • Nosotros también estábamos en medio de un hotfix en producción y quedamos bloqueados. No sé qué le está pasando a internet últimamente
    • CircleCI también está con fallas en operaciones de git por problemas para reconocer claves SSH de GitHub
    • Esta vez la IA de GitHub sí ayudó inesperadamente al decirme que revisara githubstatus.com
    • Me pregunto si desde la UI de GitHub se puede crear una rama

  • Hay un patrón común que he visto en los últimos 10 años, moviéndome entre grandes empresas y startups
    Startup → atención a clientes enterprise → rediseño complejo → idealismo → búsqueda de ganancias → producto inflado → salida de ingenieros clave → caída de calidad
    Ese ciclo también se repite en las grandes empresas de cloud (AWS, Cloudflare, GCP, etc.)
    Incluso internamente, cada servicio se divide en pequeñas unidades de negocio que se mueven con lógica de rentabilidad
    Al final, hasta la infraestructura básica se debilita por la presión de generar ganancias
    Me parece peligroso confiar en la idea de que “AWS o GCP son demasiado grandes para fallar”

    • De acuerdo. En el proceso de atender clientes enterprise es inevitable que el producto se vuelva más complejo y torpe
      Pero la deuda técnica y los problemas de seguridad de las startups tempranas también eran graves
      Al final, es natural que las grietas del sistema salgan a la luz durante el crecimiento a gran escala

  • En la página de estado de GitHub volvió a aparecer el mensaje de “algunos usuarios pueden experimentar problemas”
    Pero en realidad no solo falla HTTPS, sino también todos los push por SSH

    • Parece que quienes manejan la página de estado no pueden salir de la expresión “algunos usuarios”
      Una divulgación transparente en lugar de ese eufemismo estilo PR aumentaría más la confianza
      Además, muchas veces hasta las actualizaciones de la página de estado llegan tarde
    • Un amigo mío dijo que por un momento sí pudo hacer push, pero la mayoría sigue con errores fatal