Si hoy tu pipeline se quedó colgado en git fetch o tu runner de Actions murió sin explicación, no era tu cluster: era GitHub. La plataforma arrancó la semana con una degradación global que empezó a las 13:40 UTC y que, al cierre de esta nota —más de cinco horas y media después—, seguía sin resolverse por completo.
Qué pasó
GitHub abrió el incidente reportando "problemas de rendimiento en algunos servicios". En cuestión de minutos el alcance se fue ampliando servicio por servicio: API Requests (13:41), Actions (13:42), Webhooks (13:44), Issues (13:46), Pull Requests (13:58), Pages (15:10) y Git Operations (15:21). Copilot también entró en la lista de servicios afectados.
La cifra que publicó la propia compañía fue de ~20% de tasa de error en experiencias web y tráfico de API, y de ~50% en descargas de archives y de contenido raw de repositorios. En paralelo cayeron las piezas de identidad: autenticación SAML y OIDC, SCIM y Team Sync — es decir, justo lo que usan las organizaciones enterprise con SSO para entrar.
A las 16:36 UTC GitHub dijo haber identificado "el componente problemático" y aplicado acciones correctivas, con "señales fuertes de recuperación". Pero el incidente rebotó dos veces: a las 17:30 volvió a degradarse Git Operations y a las 18:48 la API. La última actualización, a las 19:13 UTC, apunta al mecanismo de reintentos:
"Seguimos investigando fallas esporádicas de autenticación. Deshabilitamos parcialmente los reintentos de tokens de autenticación y hemos visto mejoría; estamos monitoreando el impacto antes de aplicar la mitigación por completo."
GitHub no ha divulgado la causa raíz. Ese detalle debería llegar en el post-mortem de disponibilidad.
Por qué importa
GitHub dejó de ser "donde guardo mi código" hace años. Hoy es plano de control de despliegue para media industria: Actions dispara los builds, los OIDC tokens de Actions son los que asumen roles en AWS y Azure sin credenciales estáticas, y los git clone de imágenes base, módulos de Terraform y charts de Helm cuelgan de repos alojados ahí.
Cuando el que se degrada es el componente de autenticación, el fallo no es cosmético: un OIDC intermitente rompe despliegues a producción a mitad de camino, y un 50% de error en descargas raw revienta builds que hacen curl a un script de instalación. Es la misma lección de cada caída de Cloudflare, npm o Docker Hub: tu SLA real es el producto de los SLA de tus dependencias, y casi nadie las tiene inventariadas.
Hay un detalle que agrava el patrón: las fallas intermitentes son peores que una caída limpia. Con un 502 total, el pipeline falla rápido y tú lo sabes. Con un 20% de error, los jobs pasan a veces, los retries enmascaran el problema, y terminas con despliegues parciales y estado inconsistente que hay que auditar a mano después.
El detalle técnico
Lo poco que se sabe de la mecánica apunta a un efecto de amplificación clásico. GitHub deshabilitó parcialmente los reintentos de tokens de autenticación y con eso mejoró el cuadro. Eso huele a tormenta de reintentos: un componente de identidad degradado empieza a devolver errores, los clientes y servicios internos reintentan, el volumen extra de tráfico mantiene saturado al componente y el incidente se autoalimenta. Es el motivo por el que existen el backoff exponencial con jitter y los circuit breakers — y por el que a veces la mitigación correcta es dejar de reintentar.
Para el lado del cliente, el síntoma es exactamente el que se vio: éxito unas veces, fallo otras, sin patrón geográfico claro, y recuperaciones seguidas de recaídas conforme se van aplicando mitigaciones por capas.
Qué hacer
- Hoy: no reintentes en bucle. Pausa los workflows no críticos y revisa manualmente si algún deploy quedó a medias durante la ventana de 13:40–19:00 UTC; asume estado inconsistente hasta comprobar lo contrario.
- Autenticación: si usas SSO/SAML contra GitHub, avisa al service desk antes de que se llene de tickets de "no puedo entrar". No revoques ni rotes credenciales pensando que el problema es tuyo.
- Builds: cachea dependencias en un registry o mirror propio (Artifactory, Nexus, ECR pull-through cache,
actions/cache). Un build que baja artefactos de internet en cada corrida es un build que se cae con internet. - Runners: ten un plan B mínimo para lo crítico — self-hosted runners o un mirror del repo en otro proveedor te permiten al menos publicar un hotfix de seguridad durante la caída.
- Después: suscribe
githubstatus.com(y los status de tus otras dependencias) a un canal de guardia. Enterarte por Hacker News no es monitoreo.