Actualización sobre la disponibilidad de GitHub
(github.blog)- Tras dos incidentes recientes, GitHub está volviendo a trabajar su infraestructura y arquitectura con la disponibilidad como máxima prioridad, para adaptarse al fuerte aumento de las cargas de trabajo de desarrollo y a los agentic development workflows
- Incluso un solo pull request se conecta ampliamente con repositorios Git, Actions, búsqueda, notificaciones, permisos, webhooks, APIs, trabajos en segundo plano, cachés y bases de datos, por lo que pequeñas ineficiencias pueden escalar en acumulación de colas y propagación de dependencias
- A corto plazo, se está enfocando en reducir cuellos de botella y carga sobre la base de datos mediante la migración del backend de webhooks, el rediseño de la caché de sesiones de usuario, ajustes en los flujos de autenticación y autorización, y la ampliación de cómputo sobre Azure
- A largo plazo, está aumentando la resiliencia y la flexibilidad mediante el aislamiento de servicios clave, la reducción de puntos únicos de falla, la migración de parte del monolito en Ruby a Go, el paso a public cloud y la habilitación de una ruta multi-cloud
- Tanto la regresión de merge queue del 23 de abril como la sobrecarga de Elasticsearch del 27 de abril no provocaron pérdida de datos, y GitHub también está reforzando la transparencia al incluir métricas de availability en su status page y ampliar la divulgación incluso para incidentes menores
Contexto de la respuesta sobre disponibilidad
- GitHub resumió el estado de sus trabajos para mejorar la disponibilidad y la confiabilidad tras dos incidentes recientes
- Desde octubre de 2025 viene ejecutando un plan para ampliar la capacidad 10 veces, y en febrero de 2026 quedó claro que debía diseñar asumiendo una escala 30 veces mayor que la actual
- Un factor clave es el cambio en la forma de desarrollar software, y desde la segunda mitad de 2025 los agentic development workflows se aceleraron con fuerza
- La creación de repositorios, la actividad de pull requests, el uso de APIs, la automatización y las cargas de trabajo de repositorios grandes están creciendo rápidamente
Carga estructural revelada durante la expansión
- Un solo pull request puede tocar al mismo tiempo el repositorio Git, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches y databases
- A gran escala, incluso pequeñas ineficiencias pueden acumularse y derivar en acumulación de colas, traslado de carga a la base de datos por fallos de caché, demoras de indexación, amplificación del tráfico por reintentos e impacto sobre múltiples productos debido a dependencias lentas
- La prioridad se ordena como disponibilidad primero, luego capacidad y después nuevas funcionalidades
- Se está trabajando en paralelo en reducir trabajo innecesario, mejorar cachés, aislar servicios clave, eliminar puntos únicos de falla y mover rutas sensibles al rendimiento a sistemas dedicados
- La tarea central es reducir el acoplamiento oculto, limitar el blast radius y asegurar graceful degradation para que la presión sobre un subsistema no derribe todo el sistema
Mejoras en curso
- En el corto plazo, el enfoque está en resolver cuellos de botella que aparecieron más rápido de lo esperado
- Se movieron los webhooks a un backend fuera de MySQL, se rediseñó la caché de sesiones de usuario y también se ajustaron de nuevo los flujos de autenticación y autorización, reduciendo de forma importante la carga sobre la base de datos
- También se aseguraron más recursos de cómputo aprovechando la migración a Azure
- Después de eso, el foco pasa al aislamiento de servicios clave como git y GitHub Actions, y a reducir los puntos únicos de falla
- Se analizaron en detalle las dependencias y las capas de tráfico para identificar qué debe separarse, y se están aplicando medidas según el orden de riesgo para minimizar el impacto que distintos ataques puedan tener sobre el tráfico legítimo
- También se está acelerando la migración de parte del código sensible al rendimiento o a la escala del monolito en Ruby a Go
- Mientras avanzaba el traslado desde pequeños centros de datos propios hacia public cloud, también comenzó a impulsarse una ruta multi-cloud para el largo plazo
- Estas medidas de largo plazo son necesarias para asegurar la resiliencia, la baja latencia y la flexibilidad que se necesitarán en adelante
Repositorios grandes y respuesta para merge queue
- Se señala que un desafío de escalado más difícil que el aumento en la cantidad de repositorios es el crecimiento de los monorepos grandes
- Durante los últimos 3 meses se incrementó fuertemente la inversión para responder a esta tendencia tanto en el sistema git como en la experiencia de pull requests
- También están en marcha trabajos relacionados con el diseño de nuevas APIs para mayor eficiencia y escalabilidad, que se publicarán en una entrada de blog aparte
- Dado que es importante para repositorios donde ocurren miles de pull requests al día, también se está invirtiendo en la optimización del trabajo de merge queue
Incidente reciente 1: problema de merge queue del 23 de abril
- El 23 de abril ocurrió una regresión en el funcionamiento de merge queue de pull requests
- En merge queue con estrategia squash merge, si un merge group incluía más de un pull request, se generaba un merge commit incorrecto
- En los casos afectados, las fusiones posteriores terminaban revirtiendo sin querer cambios de pull requests ya fusionados y de commits existentes
- Durante la ventana afectada, 658 repositorios y 2,092 pull requests se vieron impactados
- Como las cifras iniciales se calcularon de forma conservadora, los números compartidos al principio fueron ligeramente mayores
- Los pull requests fusionados fuera de merge queue no se vieron afectados, y tampoco los grupos de merge queue que usaban estrategias merge o rebase
- No hubo pérdida de datos. Todos los commits permanecieron guardados en Git
- Sin embargo, el estado de la rama principal en los repositorios afectados quedó incorrecto, y no fue posible recuperar automáticamente todos los repositorios de forma segura
- incident root cause analysis: se pueden ver más detalles adicionales
- Este incidente dejó en evidencia varias fallas de proceso, y se están cambiando esos procesos para evitar que se repita un problema del mismo tipo
Incidente reciente 2: problema relacionado con search del 27 de abril
- El 27 de abril ocurrió una falla en el subsistema de Elasticsearch encargado de varias experiencias basadas en búsqueda
- El alcance incluyó algunas interfaces basadas en búsqueda de pull requests, issues y projects
- El análisis de causa raíz aún se está terminando y se publicará pronto
- Hasta ahora, lo identificado es que el clúster quedó en estado de sobrecarga, y como resultado no pudo devolver resultados de búsqueda
- Entre las posibles causas de la sobrecarga sigue abierta la posibilidad de un botnet attack, pero el análisis de causa raíz aún no concluye
- No hubo pérdida de datos y las operaciones Git y las APIs no se vieron afectadas
- Sin embargo, algunas interfaces que dependen de search no pudieron mostrar resultados en absoluto, lo que generó una gran confusión
- Este sistema era una de las áreas donde todavía no se había completado el aislamiento total para eliminar puntos únicos de falla, y hasta entonces otras áreas tenían mayor prioridad de riesgo
- Se está aplicando el mismo análisis de dependencias y trabajo de reducción de blast radius para disminuir la probabilidad y el impacto de este tipo de fallas
Refuerzo de la transparencia en incidentes
- Durante los incidentes quedó claro que los clientes quieren mayor transparencia
- Recientemente se actualizó la GitHub status page para incluir métricas de availability
- Se decidió publicar en el status no solo incidentes grandes sino también incidentes menores, con el objetivo de evitar que los usuarios tengan que adivinar si el problema está de su lado o del lado de GitHub
- También se sigue mejorando la forma de clasificar incidentes para que sea más fácil entender su magnitud y alcance
- Junto con eso, se está trabajando para mejorar cómo los clientes comparten señales y reportan problemas durante un incidente
Compromisos hacia adelante
- GitHub promete mejorar la disponibilidad, ampliar la resiliencia, escalar al nivel que requerirá el desarrollo de software del futuro y comunicarse con más transparencia
- La cantidad de repositorios afectados por el incidente del 23 de abril fue actualizada al 28 de abril de 2026
2 comentarios
Como había demasiados errores, parece que terminaron publicando un aviso a las apuradas.
Pero también me hace pensar que no fue demasiado tarde...
Ya había tantos errores que todos estaban diciendo que la gente se estaba yendo, snif.
Comentarios de Hacker News
GitHub ha tenido decenas de caídas solo en lo que va del año, y su disponibilidad y confiabilidad se han deteriorado notablemente frente al año pasado.
A este punto, el problema ya es lo bastante grave como para que den ganas de hacer dashboards y mapas de calor, y en lugares como HN o Reddit la inestabilidad de GitHub ya parece ir camino a volverse un meme.
Aun así, decir que las prioridades son "availability, capacity, new features" demuestra una lectura de la realidad demasiado relajada.
Ahora mismo las prioridades 1, 2 y 3 deberían ser todas availability, y durante al menos 6 meses no deberían hablar de otra cosa y solo dedicarse a arreglar eso.
Hace 6 meses decían que la migración a Azure era la prioridad absoluta y que por eso iban a posponer el desarrollo de funciones, pero ahora dicen que la disponibilidad vuelve a ser la prioridad principal, así que no cuadra mucho.
En ese momento decían que las limitaciones de capacidad del datacenter de Virginia por la demanda de AI y Copilot eran "existential", y ver que todavía siguen tropezando con el mismo problema lo hace aún más absurdo.
Supuestamente se había postergado el desarrollo de funciones, pero siguen saliendo funciones nuevas y cambios de UI cada semana, y hace poco también cambiaron la vista unificada de issues.
Cuesta creer que una empresa con los recursos de Microsoft siga atorada siempre en lo mismo, y también da mala espina la estrategia de comprar servicios populares para desarrolladores y moverlos todos a la misma plataforma.
En organizaciones grandes de ingeniería, las prioridades no son excluyentes, y los equipos que no pueden contribuir directamente a la prioridad central pueden seguir trabajando en otras funciones.
https://news.ycombinator.com/item?id=47912521
El hardware dedicado suele ser más predecible que la nube, y una decisión como "mejor compremos unos racks más en vez de irnos a Azure" quizá ni siquiera estaba al alcance de la dirección de GitHub.
GitHub no es un sitio que necesite rediseñarse cada 5 minutos, y a veces parece que los administradores empujan funciones nuevas solo para justificar su propia existencia.
El resultado es que, mientras más rompen cosas, más terminan generando el efecto contrario al que buscan para atraer usuarios.
La búsqueda también quedó muy degradada, y no entiendo por qué todos siguen arruinando búsquedas que antes funcionaban bien, como pasa con Google Search o YouTube.
Encima Microsoft tiene tanto Azure DevOps, que parece casi abandonado, como GitHub, y no me gusta el sistema de tickets de ninguno de los dos.
Ya estaba harto de que cada proyecto de Jira tenga configuraciones distintas, pero ahora incluso dan ganas de decir "extraño Jira".
Ese texto da la impresión de ser difícil de leer con cara seria.
Molestan bastante los gráficos sin etiquetas con números enormes, las prioridades que no encajan con la experiencia real y la falta de una admisión clara del pésimo uptime de los últimos 12 meses.
Aunque no tengan etiqueta en el eje inferior izquierdo, sí transmiten la idea central de que el crecimiento de 2023→2024→2025→2026 es muy rápido.
Se lee como que, hacia inicios o finales de 2026, estarían hablando de un crecimiento mayor que el de los 3 años anteriores juntos, y aun sin números en el eje se alcanza a ver la tendencia general.
Claro, hay que asumir que es un gráfico lineal, pero por el contexto esa suposición no parece descabellada.
Si una empresa está creciendo mucho más de lo planeado, es inevitable que aparezcan problemas de capacidad, y parece que ya no basta con meter más hardware, sino que hace falta hacer más eficiente el backend.
Los objetivos que escribieron en general también apuntan a eso.
https://x.com/kdaigle/status/2040164759836778878
No sé si es que no creen que el crecimiento actual sea exponencial, o si de verdad les parece que crecer 10 veces por año no es tan difícil.
https://damrnelson.github.io/github-historical-uptime/
Cuando dicen que "se inició una ruta multi cloud", suena a que Microsoft está admitiendo de facto que solo con Azure no puede sacar el nivel de confiabilidad que quiere.
Puede ayudar a defender la retención.
En principio apuntaba a una operación con mínima intervención humana, pero decían que ahora ya es normal que alguien toque racks o VMs manualmente, hasta pegándoles etiquetas seriales.
Ahora no encuentro el enlace.
Entre lunes y jueves, de 9 a 11 a. m. Pacific, es cuando hay más lectores activos; el fin de semana hay menos competencia, pero también menos participación.
Si el CTO de GitHub también está en la junta de Codepath.org, y ahí describen su misión como formar a la "primera generación AI-native de ingenieros, CTOs y fundadores", más o menos ya se entiende por dónde va el problema.
Mi impresión es que la estabilidad de GitHub ha empeorado bastante, y últimamente incluso cuesta confiar en los datos que muestra la web.
Desde ayer, varios colegas y yo confirmamos que en varios repos la lista de PRs aparece incompleta.
Por ejemplo, en https://github.com/gap-system/gap/pulls la pestaña muestra "Pull requests 78", pero en la vista de lista solo aparecen "35 open".
El número 78 sí es correcto, porque también se confirma con
gh pr list, pero https://www.githubstatus.com sigue marcando "all systems operational".En la CLI sí sale la lista, pero por la ruta web que pasa por búsqueda desaparecen todos.
El equipo de soporte sí reconoció el problema, pero desde entonces no han dicho nada más, y en la página de estado no hay nada salvo un issue del día 27 que quizá esté relacionado.
En algunos repos parece que se resolvió a medias, pero todavía sigue reproduciéndose en varias orgs y repos.
https://github.com/orgs/community/discussions/193388
Los PRs faltantes los encontré apenas revisando la página de branches.
Más que un bug total, puede que haya sido una decisión de producto muy mala para reducir la carga de la infraestructura.
Aun así, sí fue interesante que publicaran datos de nuevos repos/issues/commits de los últimos años.
Confirma lo que muchos ya intuían desde fuera: que los agentes están metiendo de golpe una carga adicional grande sobre GitHub.
Están sirviendo a una base de usuarios ya gigantesca y al mismo tiempo creciendo de forma exponencial como si fueran una startup, así que era inevitable que quedaran en la mira, y tampoco parece fácil que una organización así se mueva rápido.
Por otro lado, también tienen muchísimo más talento, infraestructura y dinero que una startup.
Solo hay un gráfico sin etiquetas y los números de pico actuales.
No entiendo qué se supone que hicieron con esos gráficos; parecen casi una impresión artística.
En el gráfico de commits no se explica por qué aparecen escalones grandes seguidos de una caída suave, por qué esos escalones no ocurren en puntos regulares ni por qué saltos mayores a veces tienen pendientes menores.
Los otros gráficos además se mueven con formas totalmente distintas, así que se ve todavía más raro.
No está para mostrar datos reales ni el significado de esos datos, sino solo para transmitir que "algo va hacia arriba".
Creo que los federated forges son, al final, el futuro.
Lo correcto sería que cada quien hospede sus repos en su propia infraestructura soberana, y encima montar IDs globales y metadata federada para issues, PRs, etc.
Ese tipo de índice global además es fácil de levantar, así que la disponibilidad no tendría por qué ser una gran preocupación, y nosotros también estamos trabajando en esa dirección.
Al final, si recurren a hosting de terceros, es muy probable que vuelvan a aparecer 1 a 3 proveedores grandes.
Y aunque uno haga self-hosting para evitar problemas de disponibilidad, si las dependencias siguen colgando de un servicio grande como GitHub, igual no te salvas de sus caídas.
Por eso la solución realista sigue siendo, como ahora, hacer proxy o mirroring de todo lo que uses.
Puedes tener el mismo repo en GitHub, Codeberg y self-hosted, y solo cuidar la consistencia de la rama principal.
Después de eso, puedes actualizar desde cualquiera, y basta con dejar bien puestos los enlaces en el README.
Si pudiera conectar otro forge que al menos ofrezca una API decente o webhooks y obtener la misma comodidad, me iría por completo a self-hosting.
Del lado de los agentes también tendrían que abrir la interfaz, pero si fuera una estructura de plugins, creo que se podría quitar la dependencia de GitHub y manejar el resto con MCP o skills.
Yo no tengo problema en autoalojar runners grandes, así que hace poco me pasé a Codeberg, y para tareas pequeñas de cron uso los runners que da Codeberg.
Ahí incluso tienen lazy runner para este tipo de cosas.
Lo que están haciendo ahora se ve así.
Parece que los subsidios de tokens ya absorbieron suficientes datos de entrenamiento y que el negocio de los agentic junkies ya es lo bastante grande como para echar a andar el flywheel, así que van a cortarlos y a limpiar los productos diseñados para inducir pérdidas.
https://news.ycombinator.com/item?id=47923357