GitHub confirmó el 17 de agosto, en torno a las 13:40 UTC, que estaba investigando problemas de rendimiento que resultaron ser una caída generalizada del servicio. Prácticamente ningún rincón de la plataforma quedó al margen: el sitio web, la API, Actions, Pull Requests, Issues, Webhooks, la autenticación y el propio GitHub Copilot funcionaron con errores o directamente dejaron de funcionar durante más de cuatro horas, hasta que el servicio se dio por recuperado en torno a las 18:15 UTC.
Cuánto se rompió, en números
Durante el incidente, GitHub reportó tasas de error de en torno al 20% en el tráfico general de la web y la API -- ya de por sí un problema serio a la escala de una plataforma con 225 millones de usuarios -- pero las descargas de archivos comprimidos y el acceso a contenido de repositorios en crudo llegaron a fallar hasta en la mitad de los intentos. Para cualquier pipeline de CI/CD que dependa de clonar código o descargar artefactos desde GitHub, esas cuatro horas y media no fueron una molestia menor: fueron builds fallidos, despliegues bloqueados y, en el peor de los casos, servicios en producción sin poder actualizarse.
Lo más incómodo de este incidente no es que haya pasado, es lo que dice sobre cuánto depende ya el desarrollo de software de un único proveedor
GitHub Copilot cayendo junto con el resto de la plataforma es un recordatorio directo de algo que es fácil olvidar en el día a día: para muchos equipos, GitHub ya no es solo donde vive el código, es también donde vive la herramienta que ayuda a escribirlo, donde corre la integración continua, y donde se gestionan los despliegues. Cuando esa pieza única falla, no falla "una herramienta más" -- falla buena parte de la cadena completa de desarrollo a la vez.
Una causa que, de momento, no se conoce
GitHub no ha publicado qué provocó el incidente, y ha dicho que compartirá un análisis de causa raíz cuando lo tenga. Es un dato relevante en sí mismo: el propio CTO de GitHub, Vladimir Fedorov, reconoció en abril que la compañía llevaba meses tratando de ampliar su capacidad de infraestructura diez veces, y que hacia febrero concluyó que necesitaba construir para treinta veces la escala actual -- un contexto que sitúa este incidente dentro de una tensión de capacidad ya conocida, no como un suceso aislado y sorprendente.
Qué hacer si tu flujo de trabajo depende de GitHub
Este incidente concreto ya está resuelto, pero la lección práctica no desaparece con él: si tu equipo depende de GitHub como único punto de fallo para código, CI/CD y coordinación de trabajo, merece la pena tener, aunque sea como plan de contingencia, alguna forma de seguir operando cuando GitHub no responde -- desde un espejo local de los repositorios más críticos hasta runners de CI que no dependan exclusivamente de Actions. En El Rack cubrimos en un tutorial aparte cómo montar ese espejo local con Gitea, precisamente a raíz de este incidente.
