GitHub confirma 7 horas y 47 minutos de caída el 17 de agosto

⏱️ Lectura: 12 min

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.

📑 En este artículo

1. TL;DR
2. Qué pasó en la caída de GitHub del 17 de agosto
3. Contexto e historia: el segundo incidente grave de agosto
4. Detalles técnicos y rendimiento: cuánta infraestructura sumó GitHub
5. Cómo blindar tu propio backend contra una tormenta de reintentos
6. Impacto y análisis
7. Qué sigue
8. Preguntas frecuentes
   1. ¿Cuánto duró la caída de GitHub del 17 de agosto?
   2. ¿Qué servicios de GitHub se vieron afectados?
   3. ¿Fue un ataque o un bug de código?
   4. ¿Por qué Copilot tardó más en recuperarse que el resto de los servicios?
   5. ¿Qué porcentaje de la infraestructura de GitHub corre hoy en Azure?
   6. ¿Qué es un retry budget y en qué se diferencia de un límite de reintentos fijo?
9. Referencias

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.

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.

Estrategia	Cuándo usarla	Ventaja	Limitación
Reintento fijo con backoff exponencial	Fallas puntuales y aisladas de un cliente	Simple de implementar	No frena una tormenta si miles de clientes reintentan a la vez
Retry budget	Servicios con muchos clientes concurrentes	Limita el porcentaje de tráfico que puede ser reintento, no la cantidad absoluta	Requiere métricas de tráfico en tiempo real por servicio
Circuit breaker	Dependencias que fallan de forma sostenida	Corta las llamadas a un servicio caído y evita saturarlo más	Mal calibrado, puede abrir el circuito ante fallas transitorias normales
Timeout variable con jitter	Sistemas con muchos clientes sincronizados	Evita que todos los clientes reintenten en el mismo instante	Aumenta 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 < 5; intento++) {
    const res = await fetch("https://api.copilot.example.com/v1/complete", {
      method: "POST",
      body: JSON.stringify({ prompt })
    });
    if (res.ok) return res.json();
  }
  throw new Error("fallaron los 5 intentos");
}

Este cliente reintenta de inmediato sin backoff ni presupuesto: si el servicio ya está sobrecargado, cada reintento agrega más carga en el peor momento posible.

La versión con presupuesto de reintentos limita cuánto tráfico extra puede generar el propio mecanismo de resiliencia:

class RetryBudget {
  constructor(ratioMaximo = 0.1, ventanaMs = 10000) {
    this.ratioMaximo = ratioMaximo;
    this.ventanaMs = ventanaMs;
    this.solicitudes = [];
    this.reintentos = [];
  }

  registrarSolicitud() {
    const ahora = Date.now();
    this.solicitudes.push(ahora);
    this._limpiar(ahora);
  }

  puedeReintentar() {
    const ahora = Date.now();
    this._limpiar(ahora);
    const permitido = this.solicitudes.length * this.ratioMaximo;
    return this.reintentos.length < permitido;
  }

  registrarReintento() {
    this.reintentos.push(Date.now());
  }

  _limpiar(ahora) {
    const limite = ahora - this.ventanaMs;
    this.solicitudes = this.solicitudes.filter(t => 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.

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.

Imagen destacada: Foto de Elimende Inagella en Unsplash