Resumen de la publicación
El 17 de agosto GitHub estuvo caído o degradado 7 horas y 47 minutos: pull requests, issues, Actions, webhooks, la API, Pages, la autenticación SAML/OIDC y Copilot. Cuatro días después el CTO de la empresa publicó el post-mortem y admitió que no fue un bug ni un cambio de configuración, sino que la capacidad no alcanzó.
Lo que me interesa acá no es el incidente en sí, sino lo que dejó a la vista: cuánto del ciclo de vida del software (código, revisión, CI, artefactos, deploy, identidad) tenemos concentrado en un solo proveedor. Va el análisis del post-mortem, la cuenta real de lo que cubre el SLA y una lista de cosas concretas que se pueden hacer sin irse de GitHub.
El lunes 17 de agosto, a las 10:28 de la mañana hora argentina, mucha gente en este país abrió un pull request y no cargó. Ahí empezó un día raro.
Raro porque no fue una caída limpia: GitHub no se apagó, se puso a fallar entre el 20% y el 50% de las veces. Con el sitio caído entendés rápido que hoy no se trabaja; a medias, te pasás la jornada apretando F5 y creyendo que ya vuelve.
Terminó a las 18:15. Un día laboral argentino entero, de punta a punta.
Qué se cayó el 17 de agosto (y qué no)
El incidente arrancó a las 13:28 UTC y se cerró a las 21:15 UTC: 7 horas y 47 minutos, según el propio post-mortem que publicó GitHub el 20 de agosto. En el pico, la web y la API devolvían errores en torno al 20% de los pedidos, y las descargas de archivos y de contenido crudo de repositorios, cerca del 50%.
La secuencia de la página de estado muestra cómo se propaga una falla. Según el registro que reconstruyó BleepingComputer, en menos de una hora cayeron la API, Actions y los webhooks, después issues y pull requests, luego la autenticación SAML y OIDC junto con SCIM y Team Sync, y por último Copilot.
La mayoría de los servicios volvió durante la tarde, pero Actions siguió degradado varias horas más y el servicio de tokens de Copilot fue de los últimos en recuperarse.
Ahora, lo importante: no se perdió una sola línea de código. Git es distribuido, cada clon es una copia completa con todo el historial, y eso funcionó como fue diseñado hace veinte años.
Lo que se cayó fue todo lo demás. Y «todo lo demás» resultó ser, en la práctica, casi todo tu trabajo: aprobar un cambio, correr los tests, publicar un artefacto, disparar un deploy, avisar que hay un incidente.
No fue un bug: no entró la carga
La parte del post-mortem que más me llamó la atención es la causa. Vlad Fedorov, CTO de GitHub, dice que «el tráfico llegó a un pico nuevo y un componente crítico de infraestructura en nuestro centro de datos de Central US no escaló con él». La presión de capacidad se propagó, tiró la autenticación y de ahí se llevó puesto al resto.
Y aclara algo que conviene leer dos veces: ninguno de los dos incidentes grandes de agosto vino de un cambio de código ni de configuración. No hubo deploy malo que revertir. La arquitectura ya estaba así; lo que cambió fue el tamaño de lo que le pasaba por encima.
Los números que da GitHub para explicar ese crecimiento me parecen la verdadera noticia:
- Los commits mensuales pasaron de 1.400 millones en abril a 2.900 millones en agosto. Se duplicaron en cuatro meses.
- Se mergean unos 130 millones de pull requests por mes y las corridas de Actions superaron los 100 millones mensuales.
- Azure ya se lleva alrededor del 58% de la carga de la plataforma y la mitad de las operaciones de Git, contra un 12% en mayo. La migración a Azure va a toda velocidad, en paralelo a todo esto.
Nadie duplica sus commits en cuatro meses tipeando más rápido. Eso es desarrollo asistido y agentes escribiendo, commiteando, abriendo PRs y disparando pipelines a una escala que hace un año no existía.
Y acá está el punto que quiero dejar clarito, porque es incómodo: tu equipo no generó ese tráfico, pero se comió la caída igual. Estás en una cola compartida con la industria entera, y el volumen de esa cola lo definen decisiones que no tomás vos.
Hay además un efecto amplificador: el propio GitHub reconoce que durante la recuperación los errores dispararon reintentos del lado de los clientes, que sumaron más tráfico. IDEs, extensiones y agentes de todo el mundo reintentando a la vez, sin coordinación.
Once días antes, el 6 de agosto, ya había habido un incidente de Actions de más de diez horas. Dos golpes en dos semanas no es mala suerte: es un sistema corriendo cerca del límite.
Hagamos la cuenta del SLA
Cada vez que pasa algo así aparece el consuelo del contrato: «bueno, tenemos SLA». Vale la pena mirar qué dice.
El acuerdo de nivel de servicio de GitHub Enterprise compromete un 99,9% de uptime trimestral por servicio (issues, pull requests, Git, API, webhooks, Pages, Actions y Packages). Si no lo cumple, la compensación es un crédito: 10% de lo que pagaste ese trimestre, o 25% si el uptime bajó del 99,0%.
Un trimestre tiene unos 132.000 minutos. El 0,1% que te «permite» ese 99,9% son alrededor de 2 horas y 12 minutos de caída para todo el trimestre, y el 17 de agosto solo se llevó casi cuatro veces ese presupuesto.
Y pensá qué te devuelve ese crédito. Si tu organización paga 2.000 dólares por trimestre, el 10% son 200: no cubre un día de ocho personas mirando la pantalla, ni el release que no salió, ni el hotfix que no pudiste desplegar.
El SLA no es un plan de continuidad. Es una cláusula de descuento. El plan de continuidad lo tenés que escribir vos.
Todo el ciclo de vida en un solo proveedor
Hace unos días escribí acá que tu pipeline confía en demasiada gente. Ese era el problema de en quién confiás cuando instalás dependencias de terceros. Este es otro: qué pasa cuando el lugar donde vive todo, simplemente, no está.
Hacé el ejercicio con tu equipo. Contá cuántas de estas cosas están hoy en GitHub y solo en GitHub:
- El repositorio, la revisión de código y las aprobaciones obligatorias para mergear.
- El CI y el CD completos, en Actions.
- Los artefactos (imágenes de contenedor y paquetes) en GitHub Packages o GHCR.
- Los secretos del pipeline y, muchas veces, la identidad OIDC con la que entra a tu nube.
- Issues y Projects, o sea la memoria del equipo.
- La documentación en la wiki o en Pages, y las alertas de seguridad de Dependabot.
- Copilot, que a esta altura para mucha gente es «la herramienta de trabajo».
Si marcaste cinco o más, no tenés un proveedor: tenés un único punto de falla con muy buena reputación.
Y no lo digo para acusar a nadie: yo tengo todo eso en GitHub y no me voy a ir. La integración es buena de verdad, y armar la alternativa completa cuesta plata y tiempo que la mayoría de los equipos argentinos no tiene.
Lo indefendible a esta altura es no tener ninguna respuesta preparada, porque con la carga creciendo así la pregunta ya no es si va a volver a pasar.
Qué hacer sin irse de GitHub
Esto es lo que yo haría, de lo más barato a lo más caro. Nada de acá implica migrar ni cambiar el flujo de trabajo diario.
- Un segundo remoto para el código. Un
git remote adda GitLab, Codeberg, Azure DevOps o un repositorio bare en un VPS propio, con push espejo automático. Cuesta casi nada y el código queda en dos lugares que no comparten proveedor. - Un camino de deploy de emergencia. Un runbook probado para buildear y publicar desde una máquina, sin Actions y con credenciales que no dependan del OIDC de GitHub. Ensayalo una vez por trimestre, cuando no hay incendio.
- Que los artefactos no vivan solo en GHCR. Un registro propio o un pull-through cache (una copia local que se llena a medida que bajás imágenes) alcanza para que un rollback no dependa de que GitHub esté sano.
- Usuarios «break-glass» donde uses GitHub como identidad. Si tu nube o tu tablero de observabilidad entran con SSO de GitHub, tené al menos una cuenta local de emergencia con MFA propio.
- Un canal de comunicación fuera de GitHub. Suena obvio hasta que el día del incidente descubrís que la coordinación del equipo era un issue.
- Exportá lo que no está en git. Issues, comentarios de revisión, releases y wikis: la API y
ghte lo bajan, y un cron mensual a un bucket propio resuelve el 90%. - Definí de antemano qué espera y qué no. Qué deploys tienen que poder salir con GitHub caído y quién los autoriza cuando no se puede aprobar un PR. Decidirlo en frío toma media hora; en caliente, todo el día.
- Poné githubstatus.com en el canal del equipo, por webhook o RSS. Enterarte diez minutos antes cambia la conversación de «algo raro está pasando» a «es de ellos, sigamos con otra cosa».
Si de toda esta lista hacés una sola cosa esta semana, que sea el espejo del repositorio. Es la de menor esfuerzo y la que cubre el peor escenario.
¿Cuántas horas aguanta tu equipo sin GitHub?
Le reconozco a GitHub que publicó el post-mortem con nombre y apellido, sumó más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento, y prometió límites de reintento consistentes y aislar sistemas críticos. Es más transparencia de la que dan muchos proveedores que usamos a diario.
Pero esa transparencia no me devuelve el lunes. Y la carga que reventó el sistema no va a bajar: ahora el código lo escriben también las máquinas, y eso multiplica commits, pipelines y llamadas a la API sin que nadie te consulte.
Así que la pregunta que te dejo es concreta: si mañana a las diez GitHub vuelve a fallar el 20% de las veces hasta la tarde, ¿tu equipo pierde una hora, un día o el release del mes? Contame en los comentarios qué tenés armado, que de eso se aprende más que de cualquier post-mortem.
