TL;DR:

Google Cloud suspendió incorrectamente la cuenta de producción de Railway el 19 de mayo de 2026.

La caída duró cerca de ocho horas y volvió inalcanzables todos los workloads de Railway en su punto más crítico.

Railway ahora busca sacar a Google Cloud del “camino caliente” de su data plane para reducir dependencia de un solo proveedor.

Railway, plataforma de deployment para aplicaciones, sufrió una caída global después de que Google Cloud colocó por error su cuenta de producción en estado suspendido el 19 de mayo de 2026. El incidente dejó fuera de línea su API, dashboard, bases de datos, infraestructura en GCP y, por diseño de red, también volvió inaccesibles workloads alojados en Railway Metal y AWS. La falla importa porque expone un riesgo incómodo para startups y empresas: incluso una arquitectura multi-cloud puede caer si mantiene una dependencia crítica en un solo proveedor.

Railway es una plataforma PaaS que automatiza el deployment de aplicaciones desde repositorios como GitHub, bases de datos e infraestructura cloud. En su reporte técnico, la compañía dijo que Google Cloud suspendió incorrectamente su cuenta como parte de una acción automatizada que afectó a “muchas cuentas” dentro de Google Cloud, sin aviso previo individual.

El incidente comenzó a las 22:10 UTC del 19 de mayo, cuando el monitoreo de Railway detectó fallas en sus health checks. A las 22:19 UTC, la empresa identificó la causa: su cuenta de producción de Google Cloud había sido suspendida. A las 22:29 UTC, Railway declaró el incidente y reportó errores 503 en dashboard y API, además de fallas de login.

The Register reportó que Angelo Saraceno, solutions engineer de Railway, dijo que los recursos de la compañía parecían haber sido borrados o simplemente no existir. Google explicó después que la cuenta había sido suspendida, lo que volvió invisibles esos recursos para Railway.

"Nuestros contactos en Google estaban confundidos; los clientes están furiosos"

La frase resume el punto más delicado: para Railway, el problema nació en Google Cloud; para sus clientes, el producto caído era Railway.

La caída se extendió porque el control plane dependía de Google Cloud

El dato que convierte este caso en algo más grande que una interrupción de proveedor es el efecto dominó. Railway explicó que sus workloads en Railway Metal y AWS burst-cloud seguían activos al inicio, pero sus edge proxies dependían de un control plane alojado en Google Cloud para poblar tablas de ruteo. Cuando expiró el caché de rutas, esos workloads también dejaron de ser alcanzables y empezaron a responder errores 404.

En su punto máximo, Railway reconoció que todos los workloads en todas las regiones quedaron inalcanzables. La recuperación no fue inmediata aun después de restaurar el acceso a la cuenta: discos persistentes, instancias de cómputo y networking tuvieron que volver por separado.

Los impactos principales fueron claros:

• Dashboard y API devolvieron errores 503.
• Usuarios no pudieron iniciar sesión.
• Workloads en Google Cloud quedaron fuera de línea.
• Workloads en Railway Metal y AWS se volvieron inalcanzables al expirar el caché de rutas.
• Builds y deployments se pausaron durante la recuperación.
• GitHub aplicó rate limits temporales a integraciones OAuth y webhooks de Railway por el volumen de reintentos.
• Algunos usuarios tuvieron que volver a aceptar términos de servicio porque se reiniciaron ciertos registros.

Railway acepta su parte: una dependencia crítica quedó en el lugar equivocado

Railway no descargó toda la responsabilidad en Google. En su reporte, la empresa dijo que asumía la responsabilidad por las decisiones de arquitectura que permitieron que una acción de un proveedor upstream se convirtiera en una caída de plataforma.

"Tus clientes no se preocupan por si la falla fue de Google o de Railway; ven tu producto. Tu uptime es nuestra responsabilidad, y seguiremos cumpliendo con eso."

El plan de mitigación apunta a tres cambios concretos: quitar la dependencia del control plane alojado en Google Cloud, extender shards de bases de datos de alta disponibilidad hacia AWS y Railway Metal, y mantener los servicios de Google Cloud solo como secundarios o de failover dentro del data plane.

Ese giro tiene una lectura fuerte para equipos técnicos en México y Latinoamérica que están construyendo sobre proveedores globales: multi-cloud no significa resiliencia automática. Si el ruteo, autenticación, bases de datos o control plane dependen de una sola nube, la arquitectura puede fallar como si fuera mono-proveedor.

Google Cloud ya había vivido un caso grave con UniSuper

El antecedente que vuelve más sensible esta historia es UniSuper, el fondo australiano afectado en 2024 por un incidente de Google Cloud VMware Engine. Google Cloud explicó entonces que una configuración interna dejó un parámetro en blanco, lo que asignó de forma no intencional un periodo fijo de un año y terminó en la eliminación de una Private Cloud del cliente.

Google sostuvo en ese caso que el incidente impactó a un cliente, una región y un servicio, y dijo que no era un problema sistémico. También afirmó que las copias de seguridad en Google Cloud Storage no fueron afectadas y que la recuperación se apoyó en respaldos y trabajo conjunto con UniSuper.

Axios reportó que UniSuper administraba 135,000 millones de dólares para 647,000 miembros, y que el caso dejó una lección dura sobre redundancias fuera del mismo proveedor cloud.

La diferencia con Railway es importante: el caso de UniSuper fue una eliminación ligada a Google Cloud VMware Engine; el de Railway, según la compañía, fue una suspensión incorrecta automatizada de cuenta de producción. Pero ambos episodios apuntan al mismo nervio: cuando una big tech controla la capa de infraestructura, un error administrativo o automatizado puede convertirse en una crisis operativa para terceros.

Railway resolvió el incidente a las 07:58 UTC del 20 de mayo de 2026, después de aproximadamente ocho horas de afectación. El daño reputacional, sin embargo, no se mide solo en minutos caídos. Para una plataforma que vende despliegue sencillo y uptime, la verdadera prueba empieza después: rediseñar lo suficiente para que un botón mal activado fuera de casa no vuelva a apagar toda la operación.

Fuentes: 1, 2, 3, 4, 5