La crisis de GitHub en abril de 2026: qué revela la escala 30x
Actualicé la lista de solicitudes de extracción por tercera vez. Vacío. El repositorio tenía 14 PR abiertos esa mañana (había revisado dos de ellos antes del almuerzo) y ahora la página me mostraba el tipo de borrón y cuenta nueva que solo se ve en un repositorio nuevo. Mi primer pensamiento no fue "GitHub está caído". Mi primer pensamiento fue "¿alguien del equipo cerró todo en masa mientras yo estaba en una llamada?"
Luego abrí la terminal. gh pr list. Los 14 PR. Ahí mismo. Números, títulos, autores, estados borrador. Intacto.
Esa brecha (los datos existen, pero la interfaz de usuario no puede verlos) es la forma completa de la crisis de disponibilidad de GitHub que abril de 2026 le ha pasado a la comunidad de desarrolladores. No es el tipo de interrupción en la que la plataforma se cae y una página de estado se pone roja. Es peor. Es del tipo en el que todo parece roto de tal manera que te hacen dudar de tu propio trabajo, mientras los sistemas subyacentes insisten silenciosamente en que están bien.
Al final de la semana, vi dos modos de falla distintos en la misma plataforma en siete días, leí la actualización de GitHub CTO tres veces y comencé a repensar cómo diseño cualquier cosa que toque API de GitHub. Porque la historia que hay detrás de esto no se trata realmente de dos errores. Se trata de lo que sucede cuando el punto crítico para el desarrollo de software global se ve afectado por una curva de carga para la que nadie fue diseñado, y las herramientas agentic AI que usted y yo utilizamos todos los días son parte del motivo.
La semana en que la interfaz de usuario de GitHub comenzó a mentir a los desarrolladores
Permítanme preparar el escenario adecuadamente, porque el orden de los acontecimientos importa.
La primera señal de que algo estaba estructuralmente mal se produjo el 31 de marzo de 2026, cuando GitHub tuvo lo que yo llamaría su interrupción "real": aproximadamente seis horas de disponibilidad degradada vinculada a un evento de pérdida de datos en los sistemas internos. Doloroso, muy publicitado y el tipo de cosas que todo equipo de ingeniería enfrenta un par de veces por década. Lo traté como algo único.
Entonces sucedió el 23 de abril. Fusionar corrupción de cola. Las solicitudes de extracción que ingresaban a la cola no siempre salían limpiamente por el otro lado. Algunos equipos lo lograron, otros no. Si nunca ha dependido de colas de combinación en un monorepo de alta velocidad, este es el tipo de error que erosiona silenciosamente la confianza en toda la capa de automatización: su CI dice verde, la combinación dice fusionada y luego alguien nota que la confirmación real no aterrizó como debería.
El 27 de abril es cuando se puso ruidoso. Las vistas de la lista de solicitudes de extracción comenzaron a devolver resultados vacíos o parciales. La búsqueda de problemas se interrumpió. Los filtros del tablero de proyecto dejaron de resolverse. Los primeros informes que vi en las redes sociales fueron de personas que acusaban a sus compañeros de trabajo de eliminar trabajos, lo cual es exactamente una conclusión equivocada pero muy humana. Al canal de incidentes de GitHub le tomó unas horas confirmar la causa real: el clúster ElasticSearch que impulsaba las vistas respaldadas por búsquedas se había visto abrumado, supuestamente bajo tráfico impulsado por botnet, y dejó de devolver resultados útiles mientras intentaba recuperarse.
Sin pérdida de datos. Las operaciones principales de Git funcionaron todo el tiempo. El API siguió arrojando resultados correctos a cualquiera que supiera cómo omitir la interfaz de usuario web y preguntar directamente. Pero para los millones de desarrolladores que experimentan GitHub principalmente a través de github.com/org/repo/pulls, la plataforma bien podría haber estado caída.
Esa es la parte a la que seguía dando vueltas. Los datos siempre estuvieron ahí. La infraestructura que encuentra los datos es la que falló. Y esa distinción es exactamente donde las cosas se ponen interesantes.
Por qué "GitHub está caído" es el modelo mental equivocado
Si trata a GitHub como un gran servicio monolítico, los incidentes de abril de 2026 parecen aleatorios. Seis horas aquí, un fallo en la cola de fusión allí, una interrupción de la búsqueda cuatro días después. Desde el interior, no es nada de eso: es una clase específica de modo de falla que aparece en un lugar específico de la arquitectura, repetidamente.
Aquí está el modelo mental que me ayudó a darle sentido.
El GitHub moderno consta de al menos tres servicios astackdos uno encima del otro:
- La capa Git: almacenamiento de repositorio real, push/pull, bifurcación, fusión. Ésta es la parte que nadie puede darse el lujo de romper y la que mejor se ha mantenido.
- La capa de metadatos y flujo de trabajo: pull requests, problemas, proyectos, acciones, webhooks, permisos. Este es principalmente territorio monolito de Ruby, con MySQL y PostgreSQL debajo.
- La capa de búsqueda y descubrimiento: ElasticSearch, canalizaciones de indexación, las vistas de lista y los filtros en los que realmente hace clic.
Cuando ocurrió el incidente del 27 de abril, no eliminó la capa 1. Ni siquiera eliminó la mayor parte de la capa 2. Eliminó la capa 3, y debido a que la capa 3 es lo que representa la interfaz de usuario que la mayoría de los desarrolladores usan para encontrar su trabajo, el radio de explosión percibido fue enorme, mientras que el radio de explosión funcional real estaba contenido.
El error de la cola de fusión del 23 de abril se produjo en la capa 2. El evento de pérdida de datos del 31 de marzo fue más profundo, más cercano al límite entre la capa 1 y la capa 2. Tres fallas diferentes, tres capas diferentes, todo en cuatro semanas. Eso no es mala suerte. Esa es una curva de carga que supera la arquitectura en varios lugares a la vez.
Y es la segunda parte, la curva de carga, en la que quiero dedicar el resto de esta publicación. Porque la autopsia de GitHub de CTO esencialmente admite lo obvio: a la plataforma se le pide que haga algo para lo que no fue construida, y quien lo pide somos en parte nosotros.
El número 30x que debería detener a todo ingeniero
Aquí está la línea del liderazgo de GitHub que sigo releyendo. En octubre de 2025, el equipo inició un plan de expansión de capacidad con el objetivo de crecer 10x, una cifra que se consideraría conservadora-agresiva para cualquier equipo de infraestructura. En febrero de 2026, cuatro meses después, el modelo interno decía que el objetivo real era 30x.
Lee eso de nuevo. No 10x revisado ligeramente al alza. No 12x o 15x. Triplicar el objetivo original, después de sólo unos meses de nuevos datos.
La actualización pública de GitHub cita picos de 90 millones de pull requests fusionados, 1.4 mil millones de confirmaciones y 20 millones de repositorios nuevos por mes. Incluso uno de esos números de forma aislada sería una flexión. Los tres juntos describen una plataforma cuyo perfil de carga se reescribe en tiempo real.
¿Qué cambió entre octubre y febrero? Dos cosas y están relacionadas.
La primera es la obvia: los flujos de trabajo de desarrollo agente pasaron de la novedad a la producción. He observado esta curva desde el interior de mi propio trabajo. En el tercer trimestre de 2025, los agentes eran experimentales: Claude Code era nuevo, el SDK de Anthropic Agent acababa de llegar y la mayoría de los equipos ejecutaban uno o dos flujos de trabajo automatizados en producción con mucha revisión humana. Para el primer trimestre de 2026, los mismos equipos dirigían flotas de agentes. PR-agentes creadores. Agentes fijadores de pruebas. Agentes que luchan contra la dependencia. Agentes de documentación que observaron fusiones y actualizaron documentos automáticamente.
Cada uno de esos agentes es un usuario de GitHub incansable y que nunca duerme. Abre PRs. Impulsa los compromisos. Lee problemas. Golpea el API. Activa la ejecución de acciones. Mientras que un desarrollador humano podría abrir tres o cuatro PR en un día fuerte, un agente podría abrir treinta y una flota de agentes podría abrir miles en toda una organización.
El segundo cambio es estructural. Los repositorios en sí son cada vez más grandes. Los monorepos son más comunes. Los refactores asistidos por AI generan diferencias más grandes. El código generado (aplicaciones completas con scaffolding producidas por herramientas como Claude Code en un solo mensaje) produce confirmaciones que afectan a cientos de archivos a la vez. La unidad de "cambio" en GitHub ha crecido.
Multiplique esas dos tendencias y no obtendrá un crecimiento 10 veces mayor. Se obtiene algo más cercano al crecimiento exponencial compuesto que se duplica cada seis u ocho meses y no muestra signos de desaceleración. Que es exactamente lo que describió el equipo de capacidad de GitHub.
Si se ha estado preguntando por qué su CI se siente más lento este año, por qué los retrasos en su webhook están aumentando, por qué su CLI gh a veces se bloquea durante diez segundos antes de devolver un resultado que debería ser instantáneo, esta es su respuesta. No lo estás imaginando. Estás sintiendo la curva de carga.
Lo que realmente nos dice la interrupción de ElasticSearch
Quiero volver específicamente al 27 de abril, porque la falla ElasticSearch es el incidente más útil desde el punto de vista diagnóstico de los tres. Nos dice algo específico sobre cómo falla un cuello de botella de esta escala.
ElasticSearch con el tamaño de GitHub no es un clúster al que pueda lanzar más nodos. Es un sistema distribuido estrechamente optimizado que impulsa todo, desde filtros de lista PR hasta búsquedas de emisiones, consultas de proyectos y descubrimiento de repositorios. Cuando una botnet decide atacarla (y "martillar" a escala GitHub significa decenas de miles de consultas diseñadas por segundo desde una infraestructura comprometida) no solo se ven respuestas más lentas. Ve que los procesos de indexación se quedan atrás. Verá el globo de colas de escritura. Verá que el clúster dedica más tiempo a gestionar su propia contrapresión que a responder consultas reales.
La mitigación consiste en reconstruir índices, limitar el tráfico abusivo y calentar lentamente el clúster para que vuelva a estar en servicio. Nada de eso es rápido. Nada de esto es glamoroso. Y mientras esto sucede, el resto de la plataforma se ve bien mientras una capa crítica de la experiencia del usuario se degrada.
Lo que esto expone, y lo que GitHub ahora ha reconocido públicamente, es que el subsistema de búsqueda era un punto único de falla que aún no había sido aislado del resto de la plataforma. El trabajo de confiabilidad se priorizó primero en otros lugares, en lugares considerados de mayor riesgo, y la búsqueda fue la que se llevó la peor parte. El 27 de abril hizo que esa priorización pareciera incorrecta en retrospectiva, que es la cruel aritmética de la respuesta a incidentes: cada autopsia es también una crítica de qué incendios decidió no combatir primero.
Hay una lección para desarrolladores enterrada en esto, y es el tipo de cosas que son fáciles de aceptar y difíciles de hacer: el radio de explosión de su aplicación no es el mismo que la huella de su aplicación. Los datos de GitHub nunca estuvieron en riesgo el 27 de abril. Su capa central de Git siguió funcionando. Pero debido a que la mayoría de sus usuarios experimentan GitHub a través de una interfaz de usuario basada en búsquedas, una falla en la capa de búsqueda se convirtió en un evento a nivel de plataforma en la experiencia vivida por todos. Lo que se rompió no fue lo más importante de su arquitectura. Era lo más visible.
Comencé a auditar mis propios sistemas con esa lente la semana pasada. ¿Qué subsistemas, si fallaran, harían que el resto de mi aplicación pareciera defectuosa incluso cuando no lo esté? La respuesta es incómoda. Hay más de los que me gustaría.
La hoja de ruta CTO, decodificada
La respuesta de GitHub a todo esto llegó en forma de una actualización pública de CTO, y quiero analizarla con atención porque el lenguaje está haciendo un trabajo real. Esto no es sólo "lo sentimos, agregaremos capacidad". Es una admisión estructurada de cómo serán los próximos 12 a 24 meses de ingeniería GitHub, y su forma le dice algo sobre hacia dónde se dirige toda la industria.
La hoja de ruta, tal como la leo, se divide en cinco prioridades.
1. Disponibilidad antes que capacidad, capacidad antes que características. Este es el reordenamiento principal. Durante la mayor parte de la historia de GitHub, la velocidad de las funciones fue la máxima prioridad: Copilot, Codespaces, Acciones, Proyectos v2, flujos de trabajo agentes, todos enviados en cronogramas agresivos. El nuevo orden es explícito: mantenga las luces encendidas primero, luego asegúrese de que las luces puedan permanecer encendidas con una carga de 30 veces y luego envíe las cosas nuevas. Cualquiera que haya dirigido un equipo de infraestructura ha visto este reordenamiento antes, generalmente después de un mal trimestre. Es la decisión correcta. También es una señal de que algunas funciones se ralentizarán visiblemente.
2. Reduzca el trabajo innecesario y mejore el almacenamiento en caché. Esto suena aburrido hasta que recuerde el ejemplo de PostgreSQL que dio GitHub: la limitación de velocidad mediante tablas no registradas funciona bien con menos de 1000 solicitudes por segundo, pero a 10 000 RPS necesita almacenamiento en caché Redis delante o derretirá la base de datos. Cada capa de la stack tiene umbrales como este. Escalar no es agregar hardware: es notar cada lugar donde un patrón barato solo funcionó porque la carga era baja y reconstruirlo.
3. Aislar los servicios críticos y limitar el radio de la explosión. Esto es lo que el 27 de abril debería haber evitado. El trabajo aquí es arquitectónico: asegurarse de que la búsqueda pueda fallar sin interrumpir las páginas PR, asegurarse de que la entrega de webhook pueda degradarse sin eliminar acciones, asegurarse de que los límites de velocidad aplicados a un inquilino no se trasladen a otro. Cada elemento de "aislar X" en esta lista es también una admisión de que X no fue aislado antes.
4. Migre rutas sensibles al rendimiento desde Ruby monolith a Go. Este es el elemento más táctico y el más cargado. El monolito Ruby on Rails ha sido la identidad de GitHub desde el principio; hay un famoso chiste interno que dice que GitHub es el monolito Rails con algunos servicios adicionales incorporados. Mover rutas activas a Go (y trasladar la entrega de webhooks desde MySQL a backends alternativos, algo que también mencionaron) es el tipo de trabajo que lleva años y remodela la forma en que los ingenieros se sienten acerca del código base.
5. Migración a Azure y preparación para múltiples nubes. Microsoft posee GitHub, por lo que la migración a Azure siempre estaba disponible. Pero el marco de múltiples nubes es nuevo e importante: sugiere que el liderazgo de GitHub no quiere que un solo incidente regional de un proveedor de nube se convierta en un incidente de GitHub.
Si lees esta hoja de ruta y entrecierras los ojos, es el mismo manual que han utilizado todas las plataformas de rápido crecimiento de los últimos quince años. Twitter lo publicó después de la fallida era de las ballenas. Stripe lo ejecuta continuamente. AWS lo ejecuta en cámara lenta durante décadas. Lo interesante no es que GitHub esté haciendo esto. Lo interesante es el momento y el desencadenante.
Por qué los flujos de trabajo de Agentic AI están remodelando la infraestructura de desarrollo
Esta es la parte que se conecta más directamente con lo que escribo cada semana. La razón por la que GitHub tuvo que revisar su objetivo de crecimiento de 10x a 30x en cuatro meses no es que los desarrolladores humanos de repente se vuelven tres veces más productivos. Es que la unidad de "usuario GitHub" está cambiando.
Durante la última década, un usuario de GitHub era una persona. Esa persona abrió algunos PR al día, revisó algunos más, realizó confirmaciones en ráfagas concentradas durante las horas de trabajo y se fue a casa. Su perfil de carga estaba en ráfagas, anclado en la zona horaria y, en última instancia, limitado por la cantidad de pulsaciones de teclas que un humano puede producir.
El nuevo usuario GitHub es parcial o totalmente un agente. No duerme. No tiene horario laboral. Genera un PR cada vez que CI señala una prueba inestable, una dependencia queda obsoleta, se detecta una desviación de la documentación o un indicador de característica necesita limpieza. No realiza confirmaciones pequeñas: realiza confirmaciones estructuradas generadas por herramientas que a menudo afectan a muchos archivos a la vez.
Cuando reemplaza la carga humana limitada en ráfagas por una carga de agentes continua e ilimitada, suceden tres cosas en su infraestructura simultáneamente:
- Se comprimen las proporciones pico-promedio. GitHub solía tener noches y fines de semana. Ya no es así. La línea entre "carga máxima" y "carga de fondo" desaparece, y hay que diseñar para que el pico sea el nuevo promedio.
- El tamaño medio de los objetos aumenta. Los agentes producen diferencias más grandes y descripciones PR más ricas. Los subsistemas que tocan PR (representación de diferencias, comprobaciones de fusionabilidad, revisión de subprocesos) pagan por eso con más CPU, más memoria y más trabajo de índice.
- Picos de probabilidad en cascada. Un webhook defectuoso solía significar una notificación ligeramente retrasada. Con los agentes en el bucle, un webhook defectuoso puede significar un proceso de automatización estancado, lo que significa que el agente vuelve a intentarlo, lo que significa más llamadas API, lo que significa más carga en el sistema que ya estaba teniendo problemas.
He sentido cada uno de estos en mi propio trabajo. El trimestre pasado estuve ejecutando aproximadamente cuatro agentes Claude Code en paralelo en un proyecto de cliente: uno escribiendo pruebas, otro reparándolas, otro actualizando la documentación y otro revisando PR. Cada agente se sintió barato individualmente. Juntos generaron más tráfico GitHub API en una tarde del que yo habría generado en una semana trabajando manualmente. Y yo era un desarrollador. Multiplique eso por la población global de desarrolladores agentes, que ha pasado de ser "primeros en adoptar" a ser "convencionales" aproximadamente en la misma ventana donde la carga de GitHub se duplicó.
Esta es la historia real de la crisis de disponibilidad de GitHub que se produjo en abril de 2026. No "GitHub tuvo una mala semana". Es que "el modelo de carga para el que se diseñó la plataforma ha sido reemplazado por un modelo de carga diferente, y la deuda arquitectónica de ese desajuste se hizo pública".
Si desea un encuadre más claro de cómo los flujos de trabajo agentes se convirtieron en la fuerza dominante en las plataformas de desarrollo este año, cubrí las señales anteriores de esto en la guía del SDK de Anthropic Agent y el marco de sistema operativo agente Claude Code. GitHub es la primera plataforma importante donde el proyecto de ley llegó con suficiente fuerza como para ser noticia.
Qué significa esto para cómo construyes sobre GitHub
Déjame ponerme táctico. Si está creando algo que depende de GitHub, y si es un desarrollador en activo en 2026, lo será, hay cinco ajustes concretos que vale la pena realizar en los próximos 30 días.
Primero, separe "GitHub está activo" de "GitHub UI está activo" en su monitoreo. El incidente del 27 de abril demostró que se trata de estados diferentes. Si sus herramientas esperan a que la página de estado GitHub se ponga roja antes de solucionar los problemas, llegará tarde. Agregue sondas de estado API directas contra los puntos finales específicos de los que depende su flujo de trabajo (gh pr list contra un repositorio conocido, una consulta de búsqueda que sabe que debería devolver resultados) y trate la degradación parcial como una señal de acción, no solo una señal de información.
En segundo lugar, apóyese en API y CLI, no en la interfaz de usuario web, para cualquier flujo de trabajo que no pueda permitirse perder. pull requests existió durante todo el 27 de abril. La CLI los vio todo el tiempo. Si el libro de jugadas de incidentes de su equipo depende de que los humanos hagan clic en las vistas de lista PR, su libro de jugadas de incidentes se rompe cuando se rompe la capa de búsqueda. Si el libro de estrategias pasa por gh y API, no es así.
En tercer lugar, audite el comportamiento de reintento de sus agentes. Cada flujo de trabajo de agente que he enviado alguna vez ha mostrado, en algún momento, una tormenta de reintentos durante un incidente posterior, lo que empeora el incidente para todos, incluido él mismo. El retroceso exponencial, la fluctuación y los disyuntores no son opcionales para ningún agente que toque GitHub. Si su agente no tiene los tres, la próxima interrupción será más difícil para usted y para GitHub.
Cuarto, trate las vistas respaldadas por búsquedas como fundamentalmente menos confiables que las búsquedas directas. Esta es una lección de arquitectura a largo plazo, no específica de GitHub. Cada vez que una interfaz de usuario depende de un índice de búsqueda, depende de un sistema con tiempos de reconstrucción medidos en horas. Cuando su flujo de trabajo pueda utilizar búsquedas directas (PR por número, confirmación por SHA, emisión por ID), prefiera esas. Guarde consultas respaldadas por búsquedas para casos de uso genuinamente exploratorios.
Quinto, y este es el que la mayoría de los equipos omiten: agregue un modo de "degradación elegante de GitHub" a cualquier cosa que esté creando. ¿Qué hace su herramienta cuando GitHub está activo pero es lento? ¿Cuándo arroja resultados parciales? ¿Cuándo los webhooks se retrasan cinco minutos en lugar de cinco segundos? La mayoría de las herramientas que he visto son "GitHub funciona" o "todo explota". Existe un enorme punto medio para el cual vale la pena diseñar.
En qué me equivoqué y qué veré a continuación
Seré honesto acerca de algo que asumí al llegar a esto. Cuando ocurrió el incidente del 31 de marzo, lo leí como algo único y seguí adelante. No lo conecté a la curva de carga. No anticipé que dentro de cuatro semanas veríamos dos incidentes más en diferentes capas de la misma plataforma. La corrupción de la cola de fusión del 23 de abril apenas se registró porque ninguno de mis proyectos usaba colas de fusión ese día. El 27 de abril el patrón era innegable.
La lección que estoy aprendiendo es que los incidentes de infraestructura a esta escala no suelen presentarse como una sola falla dramática. Se presentan como un grupo de fallas más pequeñas relacionadas, cada una de las cuales parece explicable de forma aislada y solo tienen sentido cuando las lees como una sola historia. Si espera a que se produzca el gran apagón, se perderá los disparos de advertencia.
Lo que estoy viendo durante el resto de 2026:
- Si la expansión de capacidad de GitHub se mantiene por delante de la curva de carga. El objetivo de 30x está en negrita, pero la curva también se está moviendo. Si los flujos de trabajo agentes se aceleran nuevamente en la segunda mitad del año, el objetivo se mueve con ellos. - Si los competidores se toman en serio. GitLab, Codeberg, Forgejo y las instancias autohospedadas de Gitea se benefician de cualquier brecha de confiabilidad sostenida en GitHub. No espero una migración masiva, pero sí espero el mensaje "¿GitHub sigue siendo el predeterminado?" La pregunta surgirá en más reuniones de arquitectura que hace seis meses. - Si los flujos de trabajo agentes en sí se vuelven más educados. Existe el argumento de que los agentes que producen esta carga podrían ser más inteligentes al respecto: procesamiento por lotes, almacenamiento en caché, respeto a las pausas y evitar sondeos innecesarios. La primera ola de herramientas agentes optimizadas para la capacidad.
La segunda ola deberá optimizarse para ser un buen ciudadano en infraestructura compartida. - Si la migración de Monolith-to-Go se realiza a tiempo. Este es el elemento de mayor apalancamiento en la hoja de ruta de GitHub, y también el más lento. Años de trabajo. Si lo ejecutan bien, GitHub con una carga de 30x se ve bien. Si no lo hacen, tendremos la misma conversación en 2027 sobre un incidente diferente.
Lo que sigo volviendo es que GitHub a esta escala ya no es solo un producto. Es infraestructura. Es el cuello de botella a través del cual fluye un porcentaje significativo del software del mundo en su camino desde la idea hasta la producción. Cuando su cuello de botella tiene un mal mes, las consecuencias se extienden de maneras que son difíciles de medir pero fáciles de sentir.
Preguntas frecuentes
¿Qué causó el error de solicitud de extracción GitHub en abril de 2026?
El error de visibilidad de la solicitud de extracción del 27 de abril se debió a que el clúster ElasticSearch que alimenta las vistas respaldadas por búsquedas se sobrecargó, supuestamente bajo tráfico impulsado por botnets. Los PR parecían faltar en las vistas de lista porque esas vistas dependen de los índices de búsqueda, pero los datos subyacentes nunca se perdieron y permanecieron accesibles a través de GitHub, API y CLI. Para conocer el desglose de la arquitectura, consulte "Por qué GitHub está inactivo es el modelo mental incorrecto" más arriba.
¿GitHub perdió algún dato durante los incidentes de abril de 2026?
No. Ninguno de los incidentes de abril de 2026 (corrupción en la cola de fusión el 23 de abril, sobrecarga de ElasticSearch el 27 de abril) implicó pérdida de datos. Las operaciones principales de Git, los repositorios y API continuaron funcionando. El incidente anterior del 31 de marzo de 2026 implicó un evento de pérdida de datos con aproximadamente seis horas de disponibilidad degradada.
¿Cuál es el plan de escalamiento 30x de GitHub?
GitHub inició una expansión de capacidad de 10 veces en octubre de 2025, luego revisó el objetivo a 30 veces en febrero de 2026 después de que el agente AI workflows duplicara la carga de la plataforma en 6 a 8 meses. El plan incluye aislar servicios críticos, migrar rutas activas de Ruby a Go, mover webhooks fuera de MySQL y continuar con la migración a Azure. Consulte "El número 30x que debería detener a todos los ingenieros" más arriba para obtener el desglose completo.
¿Cómo están afectando los agentes AI workflows a la infraestructura de GitHub?
Los flujos de trabajo agentes reemplazan la carga humana en ráfagas y anclada en la zona horaria con una carga de agentes continua e ilimitada. Los agentes abren PR, envían confirmaciones y llaman a API sin ciclos de suspensión, lo que comprime las proporciones pico a promedio, aumenta el tamaño medio de los objetos y aumenta la probabilidad de cascada durante los incidentes. La actualización CTO de GitHub cita directamente la aceleración de los flujos de trabajo agentes desde finales de 2025 como el principal impulsor del objetivo de escalamiento revisado.
¿Debería migrar de GitHub después de abril de 2026?
Para la mayoría de los equipos, no. La capa central de Git de GitHub se mantuvo estable durante los incidentes de abril de 2026, y ninguna hoja de ruta pública de GitLab, Codeberg o Forgejo coincide actualmente con la superficie de funciones de GitHub. La decisión correcta es reforzar sus herramientas contra la degradación parcial de GitHub: prefiera API y CLI a la interfaz de usuario web para flujos de trabajo críticos, agregue modos de degradación elegantes y audite sus agentes para detectar tormentas de reintentos. Consulte "Qué significa esto para la forma de construir en GitHub" más arriba.
Trabajemos juntos
¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (comstackciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Cartera: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
