GitHub se quedó sin capacidad: lo que el apagón del 17 de agosto revela sobre correr infraestructura empresarial en la era de los agentes de código

El 17 de agosto, GitHub estuvo caído siete horas y cuarenta y siete minutos. Se interrumpieron github.com, la autenticación, GitHub Actions, las APIs, pull requests, issues y Copilot —es decir, prácticamente toda la superficie que usa un equipo de desarrollo para trabajar en un día cualquiera—. Fue el segundo incidente grave del mes, después de una falla de Actions el 6 de agosto. El 20 de agosto, el CTO de GitHub, Vlad Fedorov, publicó el post mortem completo, y lo que cuenta importa mucho más allá de GitHub: es una radiografía de qué le pasa a una plataforma cuando el crecimiento impulsado por agentes de IA supera la velocidad a la que se puede escalar infraestructura.

Qué pasó el 17 de agosto

Fedorov es explícito sobre algo que suele ser la primera pregunta en cualquier post mortem: "Ninguno de los dos apagones fue causado por un cambio de código o de configuración. Ambos incidentes fueron, en el fondo, fallas de capacidad." El tráfico alcanzó un nuevo pico y un componente crítico de infraestructura en el centro de datos de Central US no escaló a la par. Esa presión de capacidad se propagó por el resto de los sistemas, provocó fallas de autenticación y arrastró consigo a múltiples servicios.

Lo que hace este caso particularmente instructivo es cómo se complicó la recuperación: algunos servicios de Copilot tardaron más en volver, y los errores en esos servicios dispararon un bucle de reintentos del lado del cliente que aumentó el tráfico justo durante la recuperación —el equipo tuvo que mitigar ese comportamiento antes de poder restaurar el tráfico de forma segura—. Es el patrón clásico de "tormenta de reintentos" (retry storm): un sistema que ya está débil recibe una ola adicional de tráfico generada por los propios clientes tratando de recuperarse, y esa ola termina retrasando la recuperación real.

La cifra que explica todo

El dato central del post mortem es el ritmo de crecimiento: los commits mensuales pasaron de 1.400 millones en abril a 2.900 millones en agosto. En el mismo período, las pull requests mergeadas mensuales llegaron a unos 130 millones y los repositorios nuevos por mes a unos 24 millones. Las ejecuciones completadas de GitHub Actions treparon de un rango de 15-30 millones a comienzos de año a más de 115 millones. Fedorov es directo sobre la causa: ese crecimiento "explica la presión sobre nuestros sistemas, pero no excusa estos apagones." The New Stack conecta el punto que el post mortem deja implícito: gran parte de ese salto responde a la adopción de agentes de codificación, que generan commits, pull requests y ejecuciones de CI a un ritmo que ningún equipo humano sostendría por sí solo.

La respuesta: comprar capacidad y correr hacia Azure

La reacción de GitHub da una idea de la magnitud del problema. Desde que se comprometieron a mejorar la confiabilidad a comienzos de año, sumaron más de 3 millones de núcleos de CPU, 120 petabytes de almacenamiento de alta velocidad y capacidad de red adicional, además de acelerar la migración a Azure. Hoy Azure sirve aproximadamente el 58% de la carga de la plataforma de GitHub y la mitad de todas las operaciones de Git, frente a apenas el 12% de la carga de plataforma en mayo. El próximo hito que describe Fedorov es una arquitectura que escale la capacidad de lectura de forma lineal con el número de lectores —lectura prácticamente ilimitada— empezando por los monorepos más grandes, que son los que más sufren cuellos de botella hoy.

Vale la pena notar lo que Fedorov no dice como excusa: en ningún momento sugiere que agregar hardware alcance por sí solo. También reconoce una falla organizacional: "A medida que aumentó el ritmo y la complejidad del cambio, nuestras prácticas operativas existentes no dieron abasto." Como resultado concreto, GitHub está aplicando límites y presupuestos de reintento consistentes, y ajustando timeouts en las interacciones entre servicios para evitar tormentas de reintentos y cargas en cascada —exactamente el patrón que agravó el apagón del 17 de agosto—, además de revisar alertas de CPU y memoria de baja prioridad que podrían anticipar fallas durante picos súbitos de tráfico.

La grieta que ya empezaron a explotar los competidores

Dos apagones graves en un mes, en la plataforma que aloja la mayor parte del código abierto y buena parte del código empresarial del mundo, no pasan desapercibidos. The New Stack señala que la inestabilidad reciente de GitHub le está dando aire a alternativas: Entire, la startup fundada por Thomas Dohmke —expresidente ejecutivo de GitHub—, apuesta por una arquitectura distribuida pensada específicamente para cargas de trabajo impulsadas por agentes, y Cursor lanzó Origin con un posicionamiento similar. Ninguna de las dos tiene, por ahora, la escala ni el efecto de red de GitHub, pero la ventana que están explotando es real: si la plataforma central del ecosistema no logra escalar al ritmo de la demanda que ella misma ayudó a crear, alguien va a intentar ocupar ese espacio.

Qué hacer con esto en tu organización

Tres cosas concretas si tu equipo administra infraestructura que hoy soporta agentes de código, CI/CD intensivo o cualquier sistema que dependa de que un tercero (o de que tu propia plataforma interna) escale al ritmo del tráfico generado por IA. Primero, revisá los supuestos de capacidad con los que se diseñó tu plataforma: si tus proyecciones de tráfico se hicieron antes de que los agentes de codificación fueran una fuente significativa de commits, pull requests o ejecuciones de pipeline en tu organización, esos números ya están desactualizados —la curva de GitHub, que más que duplicó el tráfico en cuatro meses, es una referencia razonable de cuán rápido puede moverse esto—. Segundo, si tu arquitectura tiene reintentos automáticos entre servicios sin límites ni presupuestos explícitos, es el momento de agregarlos: una tormenta de reintentos durante una recuperación parcial puede transformar un incidente manejable en uno que dura ocho horas, tal como le pasó a GitHub. Tercero, no asumas que "no hubo cambio de código" significa "no hay nada que aprender": las fallas de capacidad merecen el mismo rigor de post mortem, con cifras concretas y compromisos públicos de qué se va a cambiar, que cualquier bug en producción. Es, en definitiva, la misma disciplina de confiabilidad que cualquier shop que corre sistemas críticos —incluidos los que sostienen IBM i junto a su infraestructura cloud— ya debería estar aplicando antes de que el crecimiento impulsado por IA la ponga a prueba.

Fuentes: GitHub, "The August 17 outage, and the work ahead", por Vlad Fedorov, 20 de agosto de 2026; The New Stack, "GitHub now sees 2.9 billion commits a month — and it can't keep up", por Frederic Lardinois, 20 de agosto de 2026.