GitHub Actions volvió a caer: el riesgo real

GitHub Actions volvió a tener problemas hoy, y aunque la caída puntual se resuelva rápido, el tema de fondo no es menor: muchas empresas ya dependen de ese servicio para compilar, probar y desplegar producto todos los días. Cuando el CI/CD se detiene, no solo se frena un pipeline. Se frena el release, se acumula trabajo pendiente y, en algunos equipos, se bloquea directamente la operación.

Si tú trabajas en producto o DevOps, esta clase de incidente no se mira como una simple molestia. Se mira como una señal de diseño: ¿qué pasa si tu proveedor de automatización falla justo cuando necesitas sacar un hotfix, publicar una versión móvil o validar un cambio de infraestructura? La respuesta no debería ser “esperar a que vuelva”.

Qué significa que GitHub Actions se caiga

GitHub Actions es el motor de automatización que muchos equipos usan para correr tests, construir artefactos, ejecutar linters, publicar paquetes y desplegar a producción. Cuando falla, el impacto no siempre es igual para todos, pero sí suele tocar el mismo punto: tu capacidad de entregar software queda atada a un servicio externo.

La documentación oficial de GitHub deja claro que Actions es un servicio administrado dentro de su plataforma, con estado propio y dependencias internas. Puedes revisar el estado general en GitHub Status y la documentación de GitHub Actions para entender cómo se organiza el servicio y sus límites operativos. Eso importa porque, aunque tú escribas los workflows, la ejecución no vive en tu infraestructura.

El problema real no es que exista una caída. Los servicios caen. El problema es la frecuencia con la que una caída se convierte en una parada de negocio porque el equipo diseñó todo asumiendo disponibilidad continua. Si tu flujo de entrega depende al 100% de un proveedor externo, tu resiliencia es tan buena como la de ese proveedor.

Qué se rompe primero

En la práctica, lo primero que se rompe suele ser la cola de ejecución. Los jobs quedan pendientes, los checks de PR no terminan y los merges se frenan. Si además tienes reglas de protección en ramas, un simple fallo de CI puede impedir que nadie integre cambios.

Después viene el efecto dominó. Los releases programados se atrasan, el equipo de QA no recibe builds nuevos y producto empieza a replanificar fechas. En empresas pequeñas, eso puede significar perder una ventana comercial. En empresas medianas o grandes, puede implicar bloquear varios equipos al mismo tiempo.

Hay un caso típico que se repite: un hotfix urgente para producción. El bug está identificado, el parche está listo, pero el pipeline no corre. Si no tienes una ruta alternativa, tu tiempo de respuesta deja de depender de ingeniería y pasa a depender del estado de un servicio de terceros.

El riesgo operativo que muchos subestiman

La dependencia de CI/CD en la nube no es mala por sí misma. De hecho, tiene ventajas claras: menos mantenimiento, escalado automático y menos carga para tu equipo. El problema aparece cuando esa comodidad reemplaza cualquier plan de continuidad.

En muchas organizaciones, el CI/CD se trata como si fuera una utilidad básica, igual que el correo o la mensajería interna. Pero no siempre tiene el mismo nivel de redundancia. Si el proveedor falla, no hay un segundo nodo listo para tomar la carga. Y si no hay un plan manual, el equipo queda esperando.

Esto pega más fuerte en equipos de producto que trabajan con entregas frecuentes. Un equipo que despliega 10 veces al día no puede darse el lujo de perder 3 o 4 horas sin automatización sin que eso altere métricas, compromisos y coordinación. En LatAm, donde muchas empresas trabajan con equipos distribuidos y horarios ajustados, el costo se amplifica.

Riesgo técnico versus riesgo de negocio

No todo riesgo es igual. Una caída de Actions puede verse como un incidente técnico, pero el impacto real suele ser de negocio. Si tus despliegues están ligados a campañas, a SLAs con clientes o a fechas de lanzamiento, el problema ya no es “el pipeline no corre”. El problema es “no cumplimos”.

Mira esta diferencia en términos simples:

La tabla parece obvia, pero muchas veces no está reflejada en el diseño del sistema. Tú puedes tener observabilidad para tu app y cero observabilidad para tu cadena de entrega. Y ahí es donde el riesgo se esconde.

Dependencia invisible

El patrón es parecido al de otros servicios SaaS críticos: mientras funciona, nadie lo cuestiona. Cuando falla, todos descubren que era un punto único de fallo. Esto pasa con autenticación, con almacenamiento, con mensajería y también con CI/CD.

La diferencia es que CI/CD suele estar fuera del radar ejecutivo. No se ve en dashboards de ventas ni en reportes de soporte. Pero si se cae, afecta la velocidad de entrega, y la velocidad de entrega sí termina afectando ingresos, costos y experiencia de cliente.

Qué debería tener tu plan de contingencia

Si tu equipo usa GitHub Actions como pieza central, el plan de contingencia no puede ser un documento decorativo. Debe decir qué haces cuando el servicio no responde, quién decide, qué se puede ejecutar manualmente y cuánto tiempo toleras sin automatización.

No necesitas construir una plataforma paralela completa. Sí necesitas una ruta mínima para seguir trabajando. En algunos equipos eso significa tener runners propios. En otros, un sistema alterno de CI para emergencias. En otros, un procedimiento manual para releases críticos.

Lo clave es que el plan no se improvise durante el incidente. Si lo haces en medio de la caída, vas a perder tiempo discutiendo detalles que debiste resolver antes.

1) Define qué es crítico y qué puede esperar

No todos los workflows tienen la misma prioridad. Separa al menos tres categorías: validación de PR, despliegue a producción y tareas no críticas como generación de documentación o jobs nocturnos. Si todo es prioridad uno, nada lo es.

Un ejemplo práctico:

1. PR checks: deben tener alternativa o tolerancia temporal de merge diferido.
2. Deploy a producción: deben tener camino de emergencia documentado.
3. Jobs auxiliares: pueden pausarse sin impacto inmediato.

Ese simple corte te ayuda a decidir dónde invertir redundancia. No necesitas duplicar todo. Necesitas proteger lo que realmente detiene negocio.

2) Ten una vía de ejecución alternativa

Una opción es usar runners autoalojados para ciertos flujos críticos. Otra, mantener pipelines equivalentes en un segundo servicio de CI para emergencias. También puedes combinar ambos enfoques según el tamaño del equipo y la criticidad del producto.

La documentación de GitHub sobre self-hosted runners explica cómo ejecutar jobs en tu propia infraestructura. Eso no elimina todos los riesgos, pero sí reduce la dependencia absoluta del servicio administrado para ciertos casos.

Si trabajas en una empresa pequeña, quizá no quieras duplicar toda la configuración. En ese caso, al menos define un procedimiento manual para generar artefactos y desplegar desde una máquina controlada por el equipo. No es elegante, pero puede salvar un release.

3) Prepara releases manuales y pruebas mínimas

Cuando el CI falla, el equipo debe saber qué pruebas mínimas correr y en qué orden. No sirve decir “lo vemos a mano” si nadie sabe qué significa eso. Necesitas una lista corta y realista: unit tests críticos, build de producción, smoke test y validación de configuración.

Un flujo manual razonable puede verse así:

npm ci
npm test -- --runInBand
npm run build
npm run smoke:test

Ese ejemplo no reemplaza tu pipeline completo, pero sí te da una base para una salida de emergencia. Si tu stack usa otro gestor de paquetes o lenguaje, adapta el orden y deja el procedimiento escrito en el repositorio.

Cómo diseñar resiliencia sin duplicar costos de más

La palabra resiliencia a veces se usa como sinónimo de gastar más infraestructura, pero no siempre es así. En CI/CD, muchas mejoras cuestan más disciplina que dinero. Lo que sí cuesta dinero es descubrir tarde que dependías por completo de un único servicio.

Hay tres decisiones que suelen dar más retorno que intentar “blindarlo todo”: limitar el alcance de la dependencia, desacoplar el despliegue del build y medir cuánto te cuesta cada hora de indisponibilidad. Si no puedes cuantificar ese costo, es fácil subestimar el problema.

También conviene revisar si tu pipeline mezcla demasiadas responsabilidades. Un workflow que compila, prueba, publica, despliega y notifica todo junto es más frágil que uno dividido por etapas. No siempre vas a separar todo, pero sí puedes reducir el radio de impacto.

Separar build, test y deploy

Cuando cada paso vive en una etapa distinta, puedes recuperar parte del flujo aunque una parte falle. Por ejemplo, si el job de despliegue está bloqueado pero el build ya está listo, al menos conservas artefactos reproducibles.

Esto también ayuda a auditar incidentes. Si el build se generó correctamente pero el deploy falló por una dependencia externa, el diagnóstico es más claro. Si todo está mezclado, terminas revisando un workflow gigante con demasiadas variables.

Medir el costo real de una hora caída

Haz el cálculo con números concretos de tu negocio. Si tu equipo libera una versión que impacta ventas, soporte o cumplimiento, una hora sin CI/CD no vale “solo tiempo de ingeniería”. Vale retraso, coordinación extra y posibles errores por trabajo manual.

Un esquema simple para estimarlo:

Ese cálculo no incluye costo de oportunidad, retraso de release ni impacto en cliente. Sirve solo como piso. Si tu equipo tiene más personas o si el release es crítico, el número sube rápido.

Qué deberían revisar producto y DevOps esta semana

No hace falta esperar al próximo incidente para actuar. Si hoy dependes de GitHub Actions, hay tareas concretas que puedes revisar en una sola reunión de 45 minutos. La idea no es rediseñar toda la arquitectura, sino cerrar los huecos más obvios.

Primero, revisa qué workflows son bloqueantes para negocio. Segundo, identifica si existe una vía manual documentada para el release más crítico. Tercero, confirma quién toma decisiones cuando el servicio externo está degradado. Si esas respuestas no están claras, ya tienes trabajo pendiente.

También conviene validar el nivel de exposición por equipo. Un equipo de frontend quizá tolera mejor una pausa de CI que un equipo de infraestructura o backend con despliegues frecuentes. No todos necesitan la misma estrategia, pero todos necesitan alguna.

Checklist práctico

• Identifica los 3 workflows más críticos y documenta su impacto si se detienen.
• Define un procedimiento de emergencia para deploys críticos con pasos y responsables.
• Revisa si tus ramas protegidas bloquean merges cuando falla un check externo.
• Evalúa al menos una alternativa: runners propios, CI secundario o release manual.
• Calcula el costo estimado de 1 hora, 4 horas y 1 día sin CI/CD.
• Guarda el procedimiento en el repo y en el runbook operativo.

Si quieres llevar esto un paso más allá, puedes crear un simulacro trimestral. No hace falta dramatizarlo: basta con desactivar temporalmente un workflow no productivo y comprobar si el equipo sabe qué hacer. Ese ejercicio revela más que una reunión de status.

Tabla resumen

GitHub Actions puede volver a estabilizarse, y probablemente lo haga. Pero la pregunta útil no es cuándo se recupera el servicio. La pregunta útil es cuánto te cuesta cada minuto en que no está disponible y qué tan listo estás para seguir entregando sin él.

Si tu producto depende de despliegues frecuentes, la resiliencia de tu CI/CD no es un detalle técnico. Es parte de tu capacidad de operar. Y eso se diseña antes de la caída, no durante.