GitHub estuvo caído siete horas y cuarenta y siete minutos el 17 de agosto de 2026: la interrupción más larga que la empresa reconoce en lo que va del año. La caída de GitHub tumbó github.com, la autenticación, GitHub Actions, las APIs, los pull requests, los issues y Copilot al mismo tiempo, y dejó a miles de equipos sin poder desplegar software durante toda una jornada laboral.
La empresa publicó el post mortem el 20 de agosto de 2026, firmado por su CTO Vlad Fedorov, y admite que ninguno de los dos incidentes de agosto (el del día 6 y el del día 17) fue causado por un cambio de código o de configuración: ambos fueron fallas de capacidad.
TL;DR
- El 17 de agosto de 2026 GitHub sufrió una caída de 7 horas y 47 minutos que afectó github.com, autenticación, Actions, APIs, pull requests, issues y Copilot.- Fue el segundo incidente grave del mes, tras la falla de Actions del 6 de agosto de 2026.- La causa: un componente crítico de infraestructura en el datacenter de Central US no escaló ante un pico de tráfico récord.- Ni este incidente ni el del 6 de agosto fueron causados por un cambio de código o configuración: ambos fueron fallas de capacidad.- Copilot tardó más en recuperarse porque un bucle de reintentos del lado del cliente amplificó el tráfico durante la recuperación.- Desde abril de 2026 los commits mensuales en GitHub subieron de 1.400 millones a 2.900 millones.- GitHub sumó más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento de alta velocidad desde marzo.- Azure ya procesa cerca del 58% de la carga de la plataforma y la mitad de las operaciones de Git, frente al 12% de mayo de 2026.
Qué pasó en la caída de GitHub del 17 de agosto
El origen del problema fue simple de describir y difícil de prevenir: el tráfico llegó a un pico nuevo y un componente crítico de infraestructura en el datacenter de Central US no escaló a tiempo. GitHub explica en su reporte oficial del incidente que la presión de capacidad resultante se propagó por sus sistemas, provocando fallas de autenticación que arrastraron a github.com, Actions, las APIs, pull requests e issues.
La recuperación exigió varias acciones coordinadas en paralelo: los equipos redirigieron tráfico, aislaron la infraestructura afectada y restauraron los servicios por etapas. La mayoría de los servicios de GitHub volvieron temprano ese mismo día, pero Copilot tardó mucho más.
El motivo del retraso en Copilot fue un efecto clásico de cualquier sistema distribuido bajo estrés: los errores en esos servicios activaron un bucle de reintentos del lado del cliente que, en lugar de aliviar la carga, la aumentó justo cuando GitHub intentaba recuperarse. La empresa tuvo que mitigar ese comportamiento antes de poder restaurar el tráfico con seguridad. Es lo que en ingeniería de confiabilidad se conoce como retry storm: cada cliente que reintenta ante un error 5xx agrega más carga al sistema que ya está caído, y el sistema tarda más en recuperarse cuanto más insiste el cliente.
💭 Clave: un retry storm no es un bug de un servicio puntual: es una propiedad emergente de miles de clientes reaccionando igual ante el mismo error, al mismo tiempo.
sequenceDiagram
participant U as Cliente Copilot
participant GW as Gateway de GitHub
participant BE as Backend de Copilot
U->>GW: solicita completado
GW->>BE: reenvia la solicitud
BE-->>GW: responde error 503
GW-->>U: responde error 503
Note over U: el cliente reintenta sin espera
U->>GW: reintento inmediato
U->>GW: reintento inmediato
Note over GW,BE: el trafico de reintentos supera al original
Contexto e historia: el segundo incidente grave de agosto
Esta no fue una falla aislada. El 17 de agosto fue el segundo incidente serio de GitHub en menos de dos semanas, después de una falla en Actions el 6 de agosto de 2026. Fedorov ya había compartido en marzo y abril de 2026 el trabajo en curso para mejorar la confiabilidad de la plataforma, así que la compañía llegaba a agosto con una hoja de ruta de disponibilidad activa, no reaccionando desde cero.
El crecimiento explica buena parte de la presión: desde abril de 2026, los commits mensuales en GitHub subieron de 1.400 millones a 2.900 millones, más del doble en apenas unos meses. GitHub lo reconoce sin usarlo como excusa: ese crecimiento explica la presión sobre sus sistemas, pero la propia empresa admite que no justifica las caídas, según el blog oficial.
Detalles técnicos y rendimiento: cuánta infraestructura sumó GitHub
Como parte de los compromisos de confiabilidad de este año, GitHub priorizó tres frentes: agregar capacidad, mejorar eficiencia y eliminar cuellos de botella arquitectónicos. Desde marzo, la empresa sumó más de 3 millones de núcleos de CPU, 120 petabytes de almacenamiento de alta velocidad y capacidad de red adicional, instalando todo el hardware que la energía disponible en sus datacenters permitió, mientras aceleraba la migración a Azure.
Esa migración ya es significativa: hoy Azure sirve alrededor del 58% de la carga de la plataforma de GitHub y la mitad de todas las operaciones de Git, frente a apenas 12% de la carga de la plataforma en mayo de 2026. Ese salto en pocos meses también aceleró el trabajo para escalar los monorepos más grandes de la plataforma.
El próximo hito técnico es una arquitectura que escala la capacidad de lectura de forma lineal según el número de lectores, algo que en la práctica habilita operaciones de lectura sin límite superior artificial. GitHub la va a desplegar de forma gradual, empezando por los monorepos más grandes, donde el problema de lecturas concurrentes es más agudo.
Un solo componente sin escalar bastó para tumbar autenticación, Actions y Copilot.
Cómo blindar tu propio backend contra una tormenta de reintentos
El patrón que amplificó la caída de GitHub en Copilot (reintentos sin control durante una recuperación) es el mismo que puede tumbar cualquier backend propio durante un pico de tráfico. La solución estándar en ingeniería de confiabilidad combina tres piezas: límites de reintentos, presupuestos de reintentos (retry budgets) y timeouts variables con jitter. Es exactamente lo que GitHub anunció que va a aplicar de forma consistente entre todas sus interacciones servicio a servicio.
EstrategiaCuándo usarlaVentajaLimitaciónReintento fijo con backoff exponencialFallas puntuales y aisladas de un clienteSimple de implementarNo frena una tormenta si miles de clientes reintentan a la vezRetry budgetServicios con muchos clientes concurrentesLimita el porcentaje de tráfico que puede ser reintento, no la cantidad absolutaRequiere métricas de tráfico en tiempo real por servicioCircuit breakerDependencias que fallan de forma sostenidaCorta las llamadas a un servicio caído y evita saturarlo másMal calibrado, puede abrir el circuito ante fallas transitorias normalesTimeout variable con jitterSistemas con muchos clientes sincronizadosEvita que todos los clientes reintenten en el mismo instanteAumenta la latencia percibida en el peor caso
Un cliente ingenuo, sin ningún control, se ve así:
async function fetchCompletion(prompt) {
for (let intento = 0; intento t > limite);
this.reintentos = this.reintentos.filter(t => t > limite);
}
}
const budget = new RetryBudget(0.1, 10000);
async function fetchCompletionConPresupuesto(prompt) {
budget.registrarSolicitud();
const res = await fetch("https://api.copilot.example.com/v1/complete", {
method: "POST",
body: JSON.stringify({ prompt })
});
if (res.ok) return res.json();
if (!budget.puedeReintentar()) {
throw new Error("presupuesto de reintentos agotado, no se reintenta");
}
budget.registrarReintento();
await new Promise(r => setTimeout(r, 200 + Math.random() * 300));
return fetchCompletionConPresupuesto(prompt);
}
Con un retry budget de 10%, el servicio nunca puede recibir más de un 10% de tráfico adicional por reintentos sobre el tráfico original, sin importar cuántos clientes estén fallando a la vez. Eso es justamente lo que le faltó a la ruta de Copilot durante la caída de GitHub del 17 de agosto: nada limitaba cuánto podía crecer el tráfico de reintentos durante la recuperación.
Para confirmar que un presupuesto de reintentos está activo en producción, lo mínimo es exponer una métrica de tasa de reintentos sobre tráfico total (retry_ratio) y alertar si supera el umbral configurado, en vez de confiar en que el código nunca se salga de los límites que definiste.
⚠️ Ojo: un límite fijo de reintentos por cliente no evita una tormenta de reintentos si tenés miles de clientes reintentando en simultáneo: el límite tiene que ser sobre el tráfico agregado del servicio, no por cliente individual.
Un retry budget limita cuánto tráfico extra puede generar un reintento.Impacto y análisis
El costo real de la caída de GitHub no está en las 7 horas y 47 minutos en sí, sino en lo que representan para un ecosistema que depende de una sola plataforma centralizada para autenticación, CI/CD y control de versiones. Cuando GitHub Actions cae, no solo se detienen los despliegues: se detienen los tests, las revisiones automáticas y cualquier pipeline que dependa de un runner. Para equipos sin un plan de contingencia, la caída de GitHub se traduce directamente en horas de trabajo perdidas.
El dato más relevante del reporte no es el incidente en sí, sino lo que revela sobre la arquitectura interna de GitHub: una plataforma que en mayo de 2026 corría apenas 12% de su carga en Azure hoy corre el 58%, en medio de una migración activa. Mover la mitad de las operaciones de Git de una infraestructura a otra mientras el tráfico se duplica es, en sí mismo, un factor de riesgo adicional, aunque GitHub no lo mencione como causa directa del incidente.
Qué sigue
GitHub identificó dos cambios inmediatos a partir de los incidentes del 6 y el 17 de agosto. El primero es aplicar límites de reintentos consistentes, presupuestos de reintentos y timeouts variables en todas las interacciones servicio a servicio, para evitar tormentas de reintentos y carga en cascada como la que retrasó la recuperación de Copilot. El segundo es revisar las alertas de CPU y memoria de baja prioridad para identificar componentes que podrían fallar ante picos de tráfico repentinos, antes de que fallen en producción.
A nivel de arquitectura, el trabajo de fondo sigue siendo el mismo que Fedorov describió en marzo y abril: aislar sistemas críticos y eliminar dependencias compartidas entre ellos, para que una falla de capacidad en un componente no se propague al resto de la plataforma como ocurrió el 17 de agosto.
📖 Resumen en Telegram: Ver resumen
Probalo vos: revisá si tu backend expone hoy una métrica de retry_ratio, y si no la tiene, es un buen punto de partida antes del próximo pico de tráfico.
Preguntas frecuentes
¿Cuánto duró la caída de GitHub del 17 de agosto?
Siete horas y 47 minutos, entre el inicio del incidente y la recuperación completa de todos los servicios, incluido Copilot.
¿Qué servicios de GitHub se vieron afectados?
github.com, la autenticación, GitHub Actions, las APIs, los pull requests, los issues y Copilot.
¿Fue un ataque o un bug de código?
No. GitHub confirmó que ni este incidente ni el del 6 de agosto de 2026 fueron causados por un cambio de código o de configuración: ambos fueron fallas de capacidad ante un pico de tráfico.
¿Por qué Copilot tardó más en recuperarse que el resto de los servicios?
Porque los errores en Copilot activaron un bucle de reintentos del lado del cliente que aumentó el tráfico durante la recuperación, un efecto conocido como tormenta de reintentos (retry storm).
¿Qué porcentaje de la infraestructura de GitHub corre hoy en Azure?
Alrededor del 58% de la carga de la plataforma y la mitad de las operaciones de Git, frente al 12% de la carga de la plataforma en mayo de 2026.
¿Qué es un retry budget y en qué se diferencia de un límite de reintentos fijo?
Un retry budget limita el porcentaje de tráfico total que puede corresponder a reintentos, no la cantidad de reintentos por cliente; eso evita que miles de clientes reintentando al mismo tiempo saturen un servicio que ya está degradado.
Referencias
- The August 17 outage, and the work ahead: post mortem oficial de GitHub firmado por su CTO Vlad Fedorov, fuente primaria de todos los datos del incidente.- GitHub Status: página oficial de estado donde GitHub reporta incidentes y tiempos de recuperación en tiempo real.- Handling Overload, Google SRE Book: capítulo de referencia sobre presupuestos de reintentos y manejo de sobrecarga en sistemas distribuidos.- Microsoft Azure Documentation: documentación oficial de la infraestructura hacia la que GitHub está migrando cargas de trabajo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)