Resumen

  • GitHub cifra en 7 horas y 47 minutos el incidente del 17 de agosto. Los errores de web y API llegaron aproximadamente al 20%; los de descarga de archivos y contenido sin procesar, al 50%. También resultaron afectados Actions, Copilot y servicios empresariales de identidad.
  • La compañía vincula el origen con un sidecar de Istio que alcanzó su límite de concurrencia sin escalar. Cuatro nodos HAProxy agotaron después sus flujos y los reintentos elevaron el tráfico de tokens de Copilot desde 7.000–9.000 hasta 70.000–100.000 solicitudes por segundo.

GitHub tenía capacidad para atender en Virginia del Norte parte del tráfico que fallaba en Central US. El problema fue que cada respuesta tardía podía crear más tráfico antes de llegar allí.

La actualización final del incidente zkxwbgr0cnmx sitúa la degradación entre las 13:28 y las 21:15 UTC del 17 de agosto. Issues, pull requests, API, Actions y Copilot sufrieron errores o latencia. GitHub declara picos cercanos al 20% de error en web y API, y al 50% en descargas de archivos y de contenido bruto de repositorios.

El alcance incluyó herramientas de control empresarial. GitHub menciona la autenticación SAML y OIDC, SCIM y Team Sync. También quedaron afectados flujos de Actions en GitHub Enterprise Cloud con residencia de datos cuando dependían de definiciones públicas alojadas en GitHub.com. El parte no dice que se perdieran datos ni que se incumpliera la residencia elegida; identifica una dependencia funcional que atraviesa superficies del producto.

Según la empresa, la causa inmediata fue la saturación de balanceadores en el centro de datos Central US ante un nuevo máximo de tráfico. Un pod sidecar de Istio llegó a su límite de concurrencia. La política de escalado observaba el servicio anfitrión, pero no el límite del sidecar, por lo que no incorporó capacidad donde se había formado el cuello de botella.

La restricción se propagó hasta que cuatro nodos HAProxy agotaron sus límites de flujo. La ruta de autenticación de la pasarela perdió capacidad y aparecieron fallos de inicio de sesión y latencia en distintos productos. GitHub dice que pausar HAProxy simultáneamente en esos nodos produjo una recuperación amplia e inmediata.

Parte del tráfico problemático se desvió a Virginia del Norte, donde pudo atenderse mientras continuaba el diagnóstico en Central US. La mayoría de los servicios se había recuperado a las 16:36 UTC. Actions siguió degradado hasta aproximadamente las 18:03.

Copilot tardó más porque la recuperación creó su propia carga. Las respuestas lentas de un único endpoint interno activaron un fallo latente de reintentos en VS Code. Una operación de token fallida podía originar varias peticiones adicionales y repetir el ciclo. GitHub calcula que el tráfico del Copilot Token Service pasó de las habituales 7.000–9.000 solicitudes por segundo a entre 70.000 y 100.000.

Para reducir la amplificación, GitHub rebajó temporalmente los reintentos de la pasarela y bloqueó en los balanceadores solicitudes entrantes de tokens de Copilot con respuestas HTTP 403. Después reabrió el tráfico gradualmente por sitio. El servicio de tokens terminó de recuperarse hacia las 21:02 UTC y el incidente se cerró trece minutos más tarde.

El informe añade que varios ataques de scraping contra endpoints de codeload dificultaron la respuesta. No publica cuánto tráfico aportaron ni los presenta como causa inicial. La cadena causal divulgada sigue siendo el límite del sidecar, una política de escalado incompleta, el agotamiento de los flujos HAProxy y los reintentos optimistas.

Los documentos del producto dan contexto a esas dependencias. GitHub permite que las configuraciones de workflow reutilizables llamen a definiciones guardadas en repositorios públicos. La referencia de runners alojados incluye GitHub.com, la API, dominios de Actions y codeload.github.com entre los destinos necesarios para ejecutar trabajos y descargar acciones.

La identidad tampoco es un elemento periférico. GitHub documenta SAML SSO y SCIM como controles centrales de acceso y ciclo de vida. En su descripción de Enterprise Cloud con residencia de datos explica que las empresas usan subdominios dedicados de GHE.com y seleccionan una región. La ubicación del almacenamiento y el recorrido de una autenticación o de una definición de workflow son dimensiones distintas.

GitHub se compromete a corregir el autoscaling para que tenga en cuenta la concurrencia del sidecar, auditar límites de Istio, revisar reintentos y backoff en pasarelas y clientes, corregir el comportamiento de VS Code y mejorar la vigilancia de capacidad y la conmutación regional. El anuncio no demuestra que esas tareas ya estén terminadas. Su aplicación será la siguiente prueba verificable.

Para un cliente, la recuperación se puede medir por rutas. Leer o clonar un repositorio, llamar a una API, completar SSO, sincronizar una pertenencia, descargar un paso de workflow, iniciar un runner y obtener un token de Copilot no son la misma operación. Comprobarlas por separado evita confundir la vuelta de la web con la vuelta de todo el proceso de entrega.

Las buenas prácticas de la API REST piden respetar Retry-After, la hora de reinicio del límite y esperas crecientes tras nuevos fallos. Ese texto guía a integraciones externas, no describe la lógica interna del incidente. Aun así, fija un principio operativo relevante: insistir sin un límite convierte la demora en demanda adicional.

Fuente