Interrupción de GitHub causada por un aumento de tráfico impulsado por IA y un error de configuración

El 9 de febrero de este año, a altas horas de la noche en Beijing, decenas de millones de desarrolladores en todo el mundo abrieron GitHub y vieron la misma página.

No es 404, algo más angustiante que un 404: esa barra de advertencia amarilla que hace que la espalda de cualquier ingeniero se erice, junto con una fila de luces en la página de estado que pasan de verdes a rojas.

github.com está caído.

The API is down.

GitHub Actions está fuera de servicio.

La operación de Git falló—incluso Copilot no pudo salvarse.

Esa noche, la tubería CI/CD de alguien se detuvo en el nodo más crítico, la implementación automatizada de alguien quedó suspendida en el aire, y alguien más esperaba una PR que no podía fusionarse: detrás había una función que esperaba ser lanzada, esperando a usuarios reales.

Después del incidente, GitHub publicó un informe de accidente. La causa raíz, en términos técnicos, fue «un clúster de base de datos central responsable de la autenticación y la gestión de usuarios que se sobrecargó». Pero detrás de estas palabras se esconde una cadena de desencadenantes impactante:

Hace dos días, el equipo de ingeniería cambió el tiempo de actualización de la caché de configuración del usuario de 12 horas a 2 horas para implementar rápidamente un nuevo modelo para los usuarios. Solo se modificó este número de configuración.

Como resultado, la reescritura de caché, que originalmente se distribuía a lo largo de 12 horas, se comprimió en solo 2 horas, generando una intensa "tormenta de reescritura de caché". La cola de tareas asincrónicas se saturó instantáneamente, los componentes de infraestructura compartida colapsaron, y la reacción en cadena afectó al servicio encargado de las operaciones HTTPS Git mediante proxy, lo que finalmente agotó todas las conexiones de la plataforma.

Un número, cambiado de 12 a 2.

GitHub fue comprometido por una configuración que yo mismo modifiqué.

Pero si solo ves este cambio de configuración, probablemente te hayas perdido la parte más importante de esta historia.

El incidente del 9 de febrero no es un evento aislado.

De hecho, en los primeros tres meses de 2026, GitHub experimentó al menos ocho incidentes importantes. Solo en febrero se registraron 37 fallos de diversos tamaños. Posteriormente, el CTO de GitHub, Vlad Fedorov, admitió en un blog que durante esos dos meses GitHub no logró mantener la disponibilidad de «tres nueves» —99,9%— prometida a sus clientes empresariales.

Al revisar los archivos de fallas de los últimos dos meses, encontrarás un patrón curioso: cada incidente parece tener una causa diferente.

2 de febrero: Problema con el proveedor de cómputo de Azure, GitHub Actions fuera de servicio durante casi 4 horas, afectando a Copilot, CodeQL y Dependabot.

February 9: Cache rewrite storm, authentication database overload.

5 de marzo: Fallo del clúster de Redis; el 95 % de los flujos de trabajo de GitHub Actions no pudieron iniciarse en 5 minutos, con una latencia promedio de 30 minutos.

18 de marzo: La latencia de Webhook aumentó hasta 32 veces el nivel normal.

Cada incidente parece ser una «casualidad», y cada uno tiene una causa directa diferente. Pero la explicación de Fedorov los une en una misma historia. Él dice que detrás de estos accidentes hay tres causas estructurales comunes: «el rápido crecimiento de la carga, la fuerte acoplamiento entre servicios que permite la propagación de fallos locales, y la falta de capacidad del sistema para protegerse contra tráfico de clientes anómalos».

En términos de ingeniería, la base de GitHub ya está mostrando grietas bajo la presión de la nueva carga.

Y esta "nueva carga" tiene un nombre específico.

Datos clave

Cantidad total de commits durante todo el año 2025: aproximadamente 1 mil millones

Cantidad de commits en una semana en 2026: 275 millones

A este ritmo, se espera para todo el año 2026: 14 mil millones (un aumento del 14 veces respecto al año anterior)

Cantidad de cálculo de GitHub Actions: 500 millones de minutos por semana en 2023 → 1.000 millones en 2025 → 2.100 millones de minutos en una semana a principios de 2026

Si fueras ingeniero de infraestructura de GitHub, la comparación de los paneles de monitoreo entre 2025 y 2026 te dejaría boquiabierto.

En todo el año 2025, GitHub procesó aproximadamente mil millones de confirmaciones de código. Este número, por sí solo, es enorme y es el resultado de años de acumulación en la plataforma GitHub. Pero en 2026, la cantidad de confirmaciones en una sola semana alcanzó 275 millones. Convertido: si se mantiene esta velocidad durante todo el año, el volumen total de confirmaciones en 2026 se acercará a 14 mil millones, ¡catorce veces el total de 2025!

No es una curva de crecimiento suave, sino una pendiente pronunciada. El cambio en la cantidad de cálculo de GitHub Actions lo ilustra mejor: en 2023 se consumían 500 millones de minutos por semana, en 2025 se duplicó a 1000 millones, y luego en alguna semana a principios de 2026, se disparó directamente a 2100 millones de minutos.

¿Qué está enviando código locamente?

No es un desarrollador humano.

Los datos de GitHub muestran que los AI Agentes se están convirtiendo en el «usuario» más activo en esta plataforma. Solo la herramienta Claude Code ahora representa el 4,5% de todos los envíos en los repositorios públicos de GitHub. 2,6 millones de envíos por semana, frente a solo 100.000 a finales de septiembre de 2025: un aumento de 25 veces en tres meses.

La cantidad de PR abiertos por agentes de IA también está explotando. En septiembre de 2025, los PR generados por IA eran aproximadamente 4 millones mensuales; para marzo de 2026, este número saltó a 17 millones: más de cuatro veces más en solo seis meses.

Hay una imagen que puede ayudarte a entender qué significa esto.

Anteriormente, los «usuarios» de GitHub eran principalmente programadores humanos. Trabajaban durante el día, dormían por la noche y descansaban los fines de semana; cada confirmación implicaba reflexión, dudas y un límite en la velocidad de introducción. La carga del sistema seguía el ritmo de vida humana, presentando picos y valles predecibles.

Ahora, un número creciente de "usuarios" son Agentes de IA. No duermen, no descansan, no dudan; se pueden iniciar múltiples Agentes en paralelo para una sola tarea, y cada Agente puede realizar más entregas por hora que un ingeniero real en una semana. Más importante aún, no solo están enviando código, sino que también crean constantemente nuevos repositorios, tratando los repositorios como "productos de salida" del flujo de trabajo, no como "espacios de trabajo" humanos.

Los ingenieros de infraestructura de GitHub enfrentan ya no un problema similar con mayor tráfico, sino un problema de naturaleza completamente diferente.

Los fallos frecuentes son solo una cara del problema; GitHub también tiene otro problema más preocupante: al hacer la contabilidad, se descubre que se ha perdido dinero.

La lógica de precios original de Copilot se basó en una suposición razonable: los usuarios principalmente utilizaban la herramienta para «completar asistida», con cada interacción breve y con un cálculo predecible. El modelo de $10 mensuales para la versión personal y $19 mensuales por asiento para la versión empresarial funcionó bien durante los últimos años.

Luego, llegó la IA agente.

Los flujos de trabajo agénticos y la completación tradicional son dos especies distintas. La completación estándar de código tiene solicitudes lineales y predecibles, con ciclos de cálculo breves. En cambio, una sesión de codificación agéntica puede durar varias horas, iniciando múltiples hilos en paralelo, realizando razonamiento en múltiples pasos, autocorrección y refactorización entre repositorios: una sola sesión consume una cantidad de tokens que supera fácilmente la suscripción mensual de un usuario promedio.

GitHub enfrenta la situación de que un pequeño número de usuarios intensivos de Agentic están consumiendo recursos de cómputo equivalentes a cientos de dólares con una tarifa mensual de unos pocos dólares.

Ante esta situación, la reacción de GitHub fue directa: primero controlar el flujo, luego ajustar el precio.

A principios de este año, GitHub implementó dos mecanismos paralelos de limitación para Copilot: límite de duración de sesión y límite semanal de uso, ambos calculados según el consumo de tokens multiplicado por el peso de cálculo del modelo. Al mismo tiempo, se suspendió el registro de nuevos usuarios para algunos planes individuales de Copilot.

El 1 de junio, GitHub completó una reforma de precios más fundamental: Copilot pasó completamente a un modelo de facturación por uso, reemplazando las tarifas de suscripción con "AI Credits", donde 1 AI Credit equivale a 1 centavo de dólar, y el uso se calcula en tiempo real según el consumo de tokens.

La era de cobrar por asiento ha llegado a su fin frente a la IA agente.

Esta transformación no es solo un problema de GitHub. Es una crisis de precios colectiva que toda la industria de herramientas de IA está experimentando en 2026: cuando la IA comienza a reemplazar a los humanos en flujos de trabajo completos, y no solo a «auxiliar» el trabajo humano, todos los modelos de suscripción basados en «por persona y mes» dejarán de funcionar.

Volviendo al problema de la infraestructura. ¿Cómo planea GitHub abordar este «aumento de 14 veces»?

Hay un detalle que ilustra la gravedad de la situación:

A finales de diciembre de 2025, los flujos de trabajo de Agentic comenzaron repentinamente a acelerarse. Los ingenieros de GitHub se dieron cuenta de que 10 veces no era suficiente. En febrero de 2026, tras el grave corte de servicio, GitHub anunció que necesitaba rediseñar su arquitectura para escalar 30 veces el tamaño actual.

No es una expansión, es un rediseño.

La diferencia entre estos dos términos es grande. La escalabilidad implica aumentar la cantidad de máquinas existentes o añadir más memoria a las bases de datos existentes: la dirección no cambia, solo se incrementa la escala. Rediseñar significa que los supuestos arquitectónicos actuales fallarán sistemáticamente a una escala 30 veces mayor, y se debe repensar desde la base cómo dividir los servicios, fluir los datos y aislar fallos.

Los detalles específicos divulgados por GitHub incluyen: desacoplar servicios clave para prevenir fallos en cascada, introducir mecanismos de retroalimentación y capacidad de degradación de tráfico, implementar servidores independientes para servicios con alto tráfico, eliminar puntos únicos de fallo y mejorar la gestión de cambios: evitar implementar directamente operaciones como "cambiar el TTL de caché de 12 horas a 2 horas" sin pruebas de carga adecuadas.

Es importante destacar que GitHub no está solo.

Stripe ya ha enfrentado el problema de la creación masiva de cuentas por parte de agentes de IA, y AWS está desarrollando sistemas de identidad, registro y mecanismos de control de producción específicos para agentes. Estas acciones no son preventivas, sino que responden a señales que ya han aparecido en los paneles de monitoreo y que deben resolver.

GitHub fue solo el primero en ser comprometido — porque está en el núcleo más importante de la cadena de herramientas de IA.

Detente a pensar en la naturaleza de todo esto.

¿Qué es GitHub? La respuesta más intuitiva es que es el lugar donde los programadores almacenan su código. Pero más allá, es la infraestructura de colaboración software humana: los commits son la traza de la colaboración, los PR son contenedores de discusión, los Issues son el registro de intenciones y las Actions son tuberías de ejecución. Todo el sistema está diseñado para adaptarse al ritmo de trabajo, al pensamiento y al modelo de colaboración humanos.

El agente de IA cambió todo esto.

Cuando un agente de IA puede enviar cientos de veces de código en un día, y detrás de cada «envío» no hay pensamiento ni deliberación humana, sino solo un paso de progreso en un ciclo de tarea, ¿aún es el repositorio de código un «contenedor de colaboración»?

Cuando las herramientas de IA generan automáticamente repositorios, abren automáticamente PR, ejecutan automáticamente CI y fusionan automáticamente, ¿los desarrolladores siguen siendo el protagonista de este proceso, o ya se han convertido en meros «revisores» e incluso «observadores»?

El CTO de GitHub utilizó la frase "crecimiento rápido de la carga" al describir esta crisis. Pero esta frase probablemente subestime la naturaleza del problema: no se trata solo de un aumento cuantitativo, sino de un cambio cualitativo en la forma de uso. En el modelo antiguo, GitHub era "una herramienta para desarrolladores"; en el nuevo modelo, GitHub está convirtiéndose en "el escape de la IA", un canal de salida para flujos de trabajo automatizados.

Esto aún no tiene respuesta en términos de GitHub. Una expansión de 30 veces puede resolver problemas de tráfico, pero no puede resolver la redefinición del modelo de negocio ni la cuestión de identidad: «¿Quiénes son mis verdaderos usuarios?»

Recientemente ha ocurrido un fenómeno bastante significativo: después de una interrupción, GitHub publicó numerosos blogs técnicos que describen detalladamente la causa raíz de cada incidente, alcanzando un nivel de transparencia casi sorprendente. Algunos creen que GitHub está construyendo activamente confianza, mientras que otros piensan que está intercambiando transparencia por la paciencia de la comunidad de desarrolladores, ya que vendrán más inestabilidades durante el próximo período de reestructuración.

Una plataforma que, tras ser superada por su propio éxito, necesita desmantelarse y reconstruirse—y este proceso mismo es una prueba de si puede resistir.

Esa noche del 9 de febrero, el ingeniero que esperaba la fusión de la PR probablemente finalmente recibió el semáforo verde. Pero es posible que no se diera cuenta de que el cierre de servicio que lo hizo esperar no fue un accidente de GitHub, sino un sonido que marcó el inicio de una nueva era para la industria del desarrollo de software.

Este artículo proviene del canal de WeChat "GeekPark" (ID: geekpark), autor: AstronautMonkey