GitHub estuvo caído casi 8 horas el 17 de agosto
GitHub.com sufrió un apagón de 7 horas y 47 minutos el 17 de agosto de 2026, desde las 13:28 hasta las 21:15 UTC, que degradó casi todos los flujos de trabajo centrales para desarrolladores en la plataforma. Errores y latencias elevados afectaron simultáneamente a Issues, Pull Requests, las API REST y GraphQL, GitHub Actions y GitHub Copilot, por lo que la interrupción no se limitó a una sola función. El propio informe de GitHub, publicado en github.blog bajo el título "The August 17 outage and the work ahead", sitúa la tasa máxima de errores en torno al 20% en todo el sitio, y en torno al 50% específicamente en descargas de archivos comprimidos y en bruto. The Register, TechTimes y dev.to corroboraron el cronograma y el alcance en su propia cobertura del incidente.
| Métrica | Valor |
|---|---|
| Inicio (UTC) | 13:28 |
| Fin (UTC) | 21:15 |
| Duración | 7 horas 47 minutos |
| Tasa máxima de errores, en todo el sitio | ~20% |
| Tasa máxima de errores, descargas archivo/raw | ~50% |
La causa fue un proxy al límite, no un despliegue fallido
El informe de GitHub afirma claramente que el apagón no fue causado por un despliegue de código o configuración; fue un fallo de capacidad y monitorización dentro de la propia infraestructura de red de la empresa. El detonante fue un proxy sidecar de malla de servicios (service mesh) de Istio en un centro de datos de Central US que alcanzó su límite de concurrencia cuando el tráfico llegó con un nuevo patrón pico para el que el sistema no estaba dimensionado. Un sidecar de malla de servicios se sitúa junto a cada instancia de servicio para gestionar su tráfico de red, así que cuando uno alcanza un límite estricto bajo carga inesperada, todo lo que se enruta a través de él falla a la vez en lugar de degradarse gradualmente.
Una alerta mal configurada hizo que nadie lo viera venir
Una política interna de monitorización estaba mal configurada y no alertó a los ingenieros de GitHub cuando el proxy sidecar se acercaba a su límite de concurrencia, así que la alerta que debía activar una respuesta antes de que los usuarios notaran algo simplemente no se disparó. Ese vacío importa tanto como el propio límite de concurrencia: un límite de capacidad detectado a tiempo es una actualización silenciosa, uno detectado solo después de que los usuarios vean errores se convierte en un incidente de varias horas. GitHub afirma que corregir ese vacío de monitorización forma parte del "work ahead" mencionado en el título de su informe.
Los propios reintentos de GitHub, sobre todo de VS Code, lo empeoraron
La lógica optimista de reintentos del lado del cliente en todo el ecosistema de GitHub convirtió un proxy sobrecargado en una cascada que afectó a toda la plataforma, y GitHub señaló una tormenta de reintentos de clientes de VS Code como un factor importante en la gravedad del apagón. Cuando una solicitud falla y un cliente reintenta de inmediato sin esperar, no solo vuelve a fallar, sino que añade otra solicitud a un sistema ya sobrecargado, y multiplicado por millones de instalaciones de VS Code consultando a GitHub en segundo plano, ese patrón convirtió un problema de proxy contenido en uno de toda la plataforma. Este es el detalle que convierte el incidente, de una historia sobre la infraestructura de GitHub, en una historia sobre cómo debería construirse cualquier cliente de cualquier API.
Para cualquier empresa con su pipeline sobre GitHub, esto fue un apagón de 8 horas
La mayoría de las empresas piensan en un apagón de GitHub como una molestia para desarrolladores, algo de lo que se quejan mientras esperan, pero para cualquier empresa que haya incorporado silenciosamente GitHub Actions y Copilot a su pipeline de despliegue, 7 horas y 47 minutos sin GitHub son 7 horas y 47 minutos en los que no se puede publicar un hotfix, no se puede fusionar un parche de seguridad y, si Copilot forma parte del flujo de trabajo, se pierde una herramienta de codificación asistida por IA a mitad de tarea. Ese es un riesgo de concentración en un único proveedor escondido dentro de lo que parece "simplemente usar GitHub", y no aparece en ninguna línea de presupuesto como lo haría una suscripción de software. La lección más afilada es la tormenta de reintentos: si el propio software cliente de GitHub empeoró un apagón al reintentar de forma agresiva sin esperar, cualquier empresa que construya sus propios sistemas contra API de terceros debería auditar su propia lógica de reintentos en busca del mismo fallo, en lugar de archivarlo como un problema exclusivo de GitHub.
Leer a continuación: El Agente de IA de Wiz Hackeó a Snowflake y Culpó a Copilot | Su Segundo Alojamiento Git Se Activó Solo
