Varias interrupciones en servicios de GitHub

• Se produjeron degradaciones de disponibilidad e indisponibilidad en varios servicios de GitHub, incluidos Webhooks, Actions y Copilot
• Al principio se investigó la degradación de disponibilidad de Copilot y Webhooks, y luego el alcance de la investigación se amplió a varias interrupciones de servicios
• Actions experimentó una degradación de rendimiento por separado, y una vez identificada la causa raíz se llevaron a cabo trabajos de mitigación
• Tras mitigarse la degradación de Actions y Copilot, continuó el monitoreo de estabilidad y la verificación de los servicios restantes, y Webhooks también volvió a operar con normalidad
• Esta interrupción finalmente se cerró con estado de resuelta, y se compartirá un análisis detallado de la causa raíz en cuanto esté listo

---

Cronología de la interrupción

• Se produjo una interrupción en varios servicios de GitHub, y el alcance del impacto incluyó Webhooks, Actions y Copilot
• Inicialmente se comenzó a investigar la degradación de disponibilidad de Copilot y Webhooks
• Después, varios servicios mostraron un estado de indisponibilidad, por lo que se amplió el alcance de la investigación
• Actions experimentó por separado una degradación de rendimiento, y se siguió analizando la causa
• Una vez identificada la causa raíz, se iniciaron las medidas de mitigación
• La degradación que afectó a Actions y Copilot fue mitigada, y continuó el monitoreo para mantener la estabilidad
• Después de aplicar mitigaciones en muchos servicios, también continuó la verificación de los servicios restantes
• Webhooks también volvió a operar con normalidad
• Finalmente, esta interrupción se cerró con estado de resuelta, y se compartirá un análisis detallado de la causa raíz en cuanto esté listo

Enlaces de referencia

• Página principal de GitHub Status
• Estado actual
• Sitio de soporte

[GN⁺]

Opiniones de Hacker News

• Estaba en proceso de mover varias cosas a self-hosting en casa, y ayer por fin terminé una instancia de Forgejo dentro de mi red doméstica
  Con Linux y Windows en VM, y macOS en una Mac Mini, hasta le conecté runners de CI/CD, así que ahora el código fuente, Actions y la infraestructura real están literalmente en mi casa
  Normalmente, después de migrar a self-hosting, me toma uno o dos meses sentir que valió la pena, pero esta vez desde el día siguiente de terminar la migración ya estaba convencido de que había sido la decisión correcta, así que se sintió bastante bien

  • La idea de un homelab siempre me atrae, pero en cuanto empiezo a armarlo me canso muy rápido
    Después de pasar todo el día en el trabajo arreglando sistemas rotos, no me dan ganas de llegar a casa a asumir también mi rol de sysadmin personal
    Incluso tengo un Minisforum decente y con buen rendimiento que compré en Navidad encima del escritorio, y todavía ni lo he encendido
  • Cuando empiezas con self-hosting, te das cuenta de inmediato de lo lento que es la web moderna
    Tengo Forgejo corriendo en un NUC junto con varios servicios sobre Proxmox, y la carga de página anda por los 6 ms
    Immich no es tan rápido como eso, pero aun así sigue siendo mucho más veloz que Google Photos
  • Llevo un tiempo operando un Forgejo personal y ahí tengo todos mis side projects privados
    La UI en general es parecida, pero se siente muchísimo más fluido que GitHub. Que la razón sea simplemente que supera el 90% de uptime ya lo dice todo
    Últimamente me topo con problemas de GitHub demasiado seguido, y hasta navegar el sitio a veces es lento o directamente se queda congelado
  • Yo también hice ese cambio hace poco, y lo que más me sorprendió fue que la velocidad de Actions es mucho mejor que en GitHub
    Linux y macOS los configuré con una Mac Mini y un task file de Ansible generado por Claude, pero montar la VM de Windows sí parecía bastante doloroso
    Me pregunto si encontraste alguna forma de simplificar el proceso de despliegue
  • Ayer vi aquí una mención de gitea, investigué un poco y de inmediato me pasé a self-hosting y migré todos mis proyectos personales a Forgejo
    Eso sí, los proyectos públicos son difíciles de mover por el mercado laboral y el efecto de red de GitHub
    Ahora mismo siento que estoy jugando a ser administrador de sistemas con unas 20 instancias locales por cosas que necesito, y lo más importante es que ahora la responsabilidad de evitar pérdida de datos es mía, así que contar con backups regulares es indispensable

• Si ves https://mrshu.github.io/github-statuses/, el uptime ha bajado hasta 88.15%
  Incluso viendo componentes individuales, el mejor está en 99.78%, así que apenas llega a two nines

  • La escala de crecimiento que tienen que manejar es absurda
    En 2025 eran 1,000 millones de commits, y ahora son 275 millones por semana; incluso asumiendo crecimiento lineal, eso daría un ritmo de 14,000 millones de commits este año
    GitHub Actions también pasó de 500 millones de minutos por semana en 2023 a 1,000 millones en 2025, y esta semana va en 2,100 millones de minutos hasta ahora
    La fuente es una publicación del COO de GitHub del 2026-04-03: https://x.com/kdaigle/status/2040164759836778878
  • Me pregunto si hay correlación con que GitHub haya empezado a priorizar la migración a Azure
    https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/
  • La IA que Microsoft está empujando en realidad les está haciendo un gran favor a quienes hacen self-hosting y a los fanáticos de Linux

• Me pregunto si, aun con estas caídas repetidas, GitHub realmente está viendo una pérdida significativa de negocio
  Durante mucho tiempo en la industria se decía que la confiabilidad y el valor de marca eran clave, pero hoy parece que casi ya no les importa
  Si mi percepción está equivocada, con gusto acepto que me corrijan

  • Hace apenas 2 o 3 años, casi todos coincidían en que para desplegar software de forma estable y segura eran indispensables los repeatable builds, una chain of custody verificada y una bill of materials auditable
    Pero en cuanto los LLM mejoraron un poco, da la impresión de que toda esa conversación desapareció por completo
  • GitHub ya es una plataforma demasiado arraigada, así que estas caídas se tratan simplemente como un costo más del negocio
    Las grandes empresas están algo protegidas con instancias internas, y el resto o no se ve tan afectado o no tiene recursos para construir su propia solución o migrarse
  • Pasar de GitHub a GitLab podría ser como salir del sartén para caer al fuego
    Ojalá hubiera una alternativa realmente buena para quienes lo usan a escala

• En una ventana móvil de 90 días, parece que harían falta como 16 horas más de caída para que baje de two nines

  • Viendo https://mrshu.github.io/github-statuses/, el uptime agregado parece no llegar ni a 1 nine
  • A este ritmo, GitHub parece estar apuntándole a eight 8’s

• Supongo que no hay de qué preocuparse, porque la status page sigue diciendo que todo está en verde, 100% operativo
  Incluso cuando ni siquiera se puede acceder a una simple página estática

• Ya estamos al punto en que debería aparecer un post en HN cada vez que GitHub pase un día sin problemas
  O quizá eso simplemente significaría que volvió a su estado normal

• Hace tiempo, del lado de Bitbucket una vez perdieron un día completo de historial git en varios repos
  No fue tanto una caída como un problema de datos de su lado, y gracias a los clones locales se pudo recuperar casi todo, pero los issues y PR de ese periodo simplemente desaparecieron
  Por eso empecé a hacer gitbacker como side project
  Respaldar el repo en sí es fácil; la parte realmente interesante es el backup del metadata

• Hoy también hubo un incidente muy grave: https://www.githubstatus.com/incidents/zsg1lk7w13cf
  Dicen que por una regresión al usar merge queue junto con squash merge o rebase, algunos PR se mergearon incorrectamente entre 2026-04-23 16:05 y 20:43 UTC
  En nuestro caso, durante ese lapso se revirtieron por completo como 8 commits de la rama principal
  Es la primera vez que veo un incidente de GitHub tan grave

  • El downtime es una cosa, pero revertir silenciosamente commits de la rama principal es un nivel de falla completamente distinto
  • A nosotros nos pasó algo parecido
    Es irónico que una herramienta que supuestamente existe para evitar merge conflicts haya estado escribiendo commits corruptos directamente en la rama principal
  • A nosotros también se nos borraron varios commits de main, mientras el PR seguía apareciendo como merged
    Fue realmente muy estresante
  • A nosotros también nos revirtieron PR en varios repos
    El downtime ya es grave, pero revertir PR es un nivel más serio de falla
  • Nosotros también recibimos un correo con un PDF adjunto que incluía la lista de commits afectados y cómo recuperarlos
    Fue un desastre total

• Nuestros requisitos son relativamente simples, como git repos + actions, y como no somos un equipo que esté haciendo commits y desplegando todo el tiempo, el downtime ocasional no nos mata
  Aun así, ya estamos buscando alternativas en serio
  Justo parece que también llegó mucha gente a buscar alternativas, porque hasta SourceHut se cayó. Estaba abajo cuando escribí esto y ya volvió
  https://sr.ht/

  • Me pregunto qué tal será tangled.org

• Solo hoy hubo tres incidentes, cada uno de casi más de una hora, pero el estado diario sigue completamente en verde y figura como sin downtime registrado
  Tampoco se ven esencialmente distintos de los incidentes de antes que sí aparecían con barras rojas; la única diferencia parece ser que no duraron varias horas
  Entonces no entiendo qué se supone que significan esas barras verdes
  Me hace sospechar si primero tiene que quejarse suficiente gente para que luego lo cambien a algo que no sea verde, o si los incidentes del mismo día solo aparecen un rato en el tooltip y después discretamente se olvidan
  Hasta ahora, en las fechas verdes anteriores no aparece ningún incidente en el tooltip, pero hoy sí se ven varios, así que de una forma u otra se siente como una visualización deliberadamente engañosa