1 puntos por GN⁺ 2026-02-10 | 2 comentarios | Compartir por WhatsApp
  • Se reportó una degradación del rendimiento en algunos servicios de GitHub, junto con retrasos en la entrega de notificaciones
  • La latencia promedio aumentó desde unos 50 minutos al inicio hasta un máximo de 1 hora 20 minutos
  • Después se llevó a cabo una recuperación gradual, y el retraso se redujo de 1 hora → 30 minutos → 15 minutos
  • Se informó que el problema quedó resuelto y el incidente cerrado el 9 de febrero de 2026 a las 19:29 UTC
  • GitHub planea publicar más adelante un análisis de causa raíz (RCA)

Resumen del incidente de retraso en las notificaciones de GitHub

  • GitHub informó que hubo una degradación del rendimiento en algunos servicios
    • En la etapa inicial, las notificaciones no se entregaban con normalidad
    • La investigación sobre la causa del problema seguía en curso

Evolución del retraso en las notificaciones

  • En la primera actualización se indicó un retraso promedio de 50 minutos
    • GitHub señaló que estaba aplicando medidas de mitigación
  • En una actualización posterior, el retraso empeoró hasta 1 hora 20 minutos, aunque se observaron señales de recuperación
  • La recuperación avanzó gradualmente y el tiempo de retraso se redujo de 1 hora → 30 minutos → 15 minutos
    • Se explicó que estaban procesando el backlog (notificaciones acumuladas)
  • Finalmente, el problema de retraso en las notificaciones quedó resuelto y se reanudó la entrega normal

Cierre del incidente y medidas posteriores

  • El incidente quedó completamente resuelto el 9 de febrero de 2026 a las 19:29 UTC
  • GitHub agradeció a los usuarios por su paciencia y comprensión
  • Los resultados del análisis de causa raíz (Root Cause Analysis) se publicarán cuando estén listos

Notificaciones a usuarios y función de suscripción

  • Los usuarios pueden suscribirse a las actualizaciones del incidente por correo electrónico, SMS, Slack, Webhook, entre otros
  • Al suscribirse, deben aceptar la política de privacidad y los términos de servicio de GitHub y Atlassian
  • El sitio está protegido por Google reCAPTCHA

Resumen

  • Este incidente fue un problema de retraso en el sistema de notificaciones de GitHub, con una recuperación escalonada durante unas 4 horas
  • El servicio ya volvió a su estado normal, y se espera un informe de análisis adicional

2 comentarios

 
joyfui 2026-02-10

Parece que no fui el único al que GitHub le empezó a arrojar errores hoy de madrugada.

 
GN⁺ 2026-02-10
Comentarios en Hacker News
  • Como GitHub ya no publica las estadísticas de disponibilidad del servicio, me puse a parsear los datos por mi cuenta.
    En este momento, considerando el servicio completo, parece estar en el nivel de “single 9”.
    Se puede ver en la página GitHub Statuses

    • Me hace recordar la antigua página de estado de GitHub. En ese entonces mostraban el tiempo de actividad real con transparencia, así que no sorprende que la cambiaran por la página actual en cuanto empezó a mostrar la verdad.
      También leí bien la explicación con enlace a archive.org
    • Decir que está en “single 9” tomando todo el servicio como un solo indicador no tiene sentido por cómo se calcula la disponibilidad.
      Las cifras por área están bien, pero juntar todos los servicios en una sola métrica no significa nada.
      La mayoría están por encima de 99.5%, y Copilot parece ser la única excepción
    • Es interesante que la cifra total de Copilot sea la más baja.
      Lo uso todos los días, pero casi no he sentido problemas. Tal vez el momento en que se registra un incidente se refleja tarde
    • No entiendo que hayan clasificado la caída de hoy como “minor”.
      La UI web casi no funcionaba, así que me pregunto si GitHub no estará minimizando la gravedad del incidente
    • Es un gran proyecto. Gracias por compartirlo así
  • Hasta hace unos años no pensaba que el dominio de GitHub pudiera verse amenazado.
    Pero si sigue operando con esta inestabilidad, creo que quedará registrado como uno de los grandes autogoles de la industria

    • Parece que desde la migración “existencial” a Azure del año pasado la disponibilidad bajó uno o dos escalones
    • Justo ahora estoy viendo la página “Migrate from GitHub” de la documentación de GitLab.
      Si también puede traer issues y proyectos, estoy pensando seriamente en moverme
    • No creo que sea solo un problema operativo, sino de arquitectura y calidad del código.
      Basta ver el producto self-hosted de GitHub Enterprise para darse una idea de lo complejo que es
    • No tengo pruebas, pero sospecho que las caídas frecuentes recientes podrían ser un efecto colateral de la estrategia centrada en IA
    • Creo que es resultado de que Microsoft los forzó a migrar a Azure y priorizó las cargas de trabajo de IA.
      GitHub es la gallina de los huevos de oro de los datos de desarrollo a nivel mundial, y si sigue tan inestable, la franquicia misma corre riesgo.
      Windows 11 tampoco va bien, y GitHub podría perder su papel como base del desarrollo moderno
  • Estaba atendiendo un bug de seguridad de Caddy cuando GitHub se cayó, así que al abrir el reporte solo aparecía la página del unicornio.
    Quería aprovechar dos horas sin hijos para concentrarme, y ahora me preocupa que este incidente retrase el ciclo de retroalimentación hasta mañana.
    Aun así, estoy agradecido porque GitHub Sponsors me ayuda a ganarme la vida

    • Me da curiosidad saber qué bug de seguridad era
    • Quisiera preguntar si alguna vez ha considerado una plataforma alternativa. Desde la perspectiva de alguien que administra su propio servidor, la seguridad es importante
  • Se puede ver en tiempo real cómo GitHub se fragmenta y explota en pedazos.
    La página GitHub Status History ya es casi una comedia

    • Es 9 de febrero y ya van 14 incidentes.
      Es irónico ver que otra vez se desarrolla así la etapa de “salvador” de la industria de la IA.
      Artículo relacionado: enlace de The Verge
    • En broma dicen que para revertir esta tendencia hace falta hacer más vibe coding
    • Aun así, está bien que GitHub lo publique con transparencia.
      Como no esconden el downtime, al menos se puede reaccionar, y seguramente luego habrá una retrospectiva
    • Esto probablemente seguirá hasta que termine la migración a Azure
    • Ojalá hubiera una visualización anual como el gráfico de contribuciones del perfil de GitHub
  • En lo que va del año, GitHub ha tenido tantos incidentes que casi actualiza la página de estado todos los días.
    Si ves el historial de estado, esto no es normal ni siquiera para un servicio grande.
    Ya hasta existe la broma de que GitHub Actions se cae todos los días cerca de las 4 p. m.
    Ojalá publiquen internamente las causas y las medidas correctivas

    • Desde la aparición de los agentes de programación, es muy probable que el tráfico operativo haya aumentado 100 veces.
      GitHub fue diseñado originalmente para otra escala, y de repente le cayó una carga de otra dimensión
  • Al principio, la página de estado solo mostraba demoras en las notificaciones, pero en realidad al entrar a un PR seguía apareciendo la página del unicornio.
    Después apareció una página de estado separada para los PR, y al final se expandió como un problema de todo el servicio.
    Enlace al incidente relacionado

    • Se agregó la entrada “Investigating degraded performance for some services”.
      A las 16:10 UTC no estaba, pero apareció unos minutos después
    • Al aprobar un PR, la API JSON devuelve una página de error HTML. Parece que por dentro todo está completamente enredado
    • Yo también veo errores 500 con frecuencia. La latencia también se disparó.
      Enlace de monitoreo
    • Al entrar a los detalles de un commit también solo aparece la página del unicornio
    • Ni siquiera funcionan los comandos de git
  • En las últimas semanas terminé la migración a Forgejo.
    Nuestra empresa quiere reducir la dependencia de las grandes nubes, así que no tenía sentido que una caída de GitHub/Azure detuviera infraestructura crítica.
    El proceso de transición fue fluido, y también estamos haciendo algunos desarrollos personalizados.

    1. Creamos runners basados en Firecracker para ejecutar CI en entornos VM desde Forgejo Actions
    2. Estamos preparando una propuesta para agregar una función de grupos de variables de entorno
      La comunidad ha sido muy acogedora, y ojalá Forgejo siga creciendo
      Enlace de la empresa, enlace a la discusión de la propuesta
    • Si están en Londres, me da curiosidad por qué usan un dominio .eu, y también dónde están los servidores y quién es el proveedor de hosting
  • La inestabilidad de GitHub ya no es aceptable.
    Si en adelante puedo influir en la elección del repositorio de código, voy a tratar de evitar GitHub

    • Las funciones se pueden reemplazar suficientemente bien con otros forges.
      Aun así, la descubribilidad y las señales sociales de GitHub (estrellas, forks) siguen siendo atractivas.
      Lo realista es usar un forge interno (GitLab, Gitea, etc.) y hacer mirroring en GitHub.
      Irónicamente, si GitHub estuviera mejor, habría pagado un plan, pero ahora solo uso el gratuito y gasto mi dinero en otra parte
  • En los últimos 3 meses ha habido 3 caídas masivas.
    También está indicado en el historial de estado

    • Me pregunto quién se fue del equipo últimamente. Tal vez se fue alguien con conocimiento clave, o quizá movieron operaciones a otra región
    • Estamos a dos semanas de lanzar un MVP y otra vez hay una caída; es desesperante. La confiabilidad es demasiado baja
    • Agregan en broma si esto también será culpa del vibe coding
  • La situación actual parece el resultado de que la IA reemplazó a los ingenieros

    • “Sí, perdón. Borré tu base de datos.”, responde alguien en tono de broma
    • En realidad, tengo entendido que estas caídas ocurren porque GitHub está migrando a Microsoft Azure
    • Es una sátira como si Tay.ai y Zoe.ai estuvieran peleando internamente y por eso no pudieran mantener el servicio