Informe de incidente: 19 de mayo de 2026 – Suspensión de cuenta de GCP
(blog.railway.com)- Caída general de la plataforma de Railway durante unas 8 horas a partir del 19 de mayo de 2026 a las 22:20 UTC, causada directamente por la suspensión de la cuenta de producción de Google Cloud
- El dashboard y la API devolvieron de inmediato errores 503, y la infraestructura de cómputo, bases de datos, plano de control y burst-compute alojada en Google Cloud quedó fuera de línea
- Las cargas de trabajo en Railway Metal y AWS siguieron ejecutándose, pero el proxy de borde dependía de la API del plano de control en Google Cloud, por lo que, tras expirar la caché de rutas, comenzaron a propagarse errores 404
- Incluso después de recuperar el acceso a la cuenta, fue necesario restaurar por separado los discos persistentes, instancias de cómputo y redes, y el rate limiting de GitHub sobre OAuth y webhooks bloqueó adicionalmente inicios de sesión y builds
- Railway reconoció su responsabilidad por una decisión de arquitectura que permitió que la acción de un único proveedor ascendente derivara en una caída total, y está llevando a cabo un rediseño para sacar a Google Cloud del hot path del plano de datos
Impacto
- Desde el 19 de mayo de 2026 a las 22:20 UTC hasta aproximadamente las 06:14 UTC del 20 de mayo, Railway sufrió una caída general de la plataforma durante 8 horas
- Google Cloud suspendió el servicio de la cuenta de producción de Railway, lo que dejó fuera de línea la API, el plano de control, las bases de datos y la infraestructura de cómputo alojada en Google Cloud
- Los usuarios vieron de inmediato errores 503 en el dashboard y la API, y no pudieron iniciar sesión, con mensajes como
"no healthy upstream"y"unconditional drop overload" - Todas las cargas de trabajo alojadas en cómputo de Google Cloud quedaron fuera de línea
- Las cargas de trabajo en Railway Metal y en el entorno burst-cloud de AWS siguieron ejecutándose, pero el proxy de borde de Railway dependía de la API del plano de control alojada en Google Cloud para poblar la tabla de enrutamiento
- Cuando expiraron las rutas de red almacenadas en caché, también dejaron de ser accesibles las cargas de trabajo fuera de Google Cloud, y el plano de control de red devolvió errores 404 al no poder resolver rutas hacia instancias activas
- En el punto de máximo impacto, las cargas de trabajo de Railway en todas las regiones quedaron inaccesibles
- Durante la recuperación del entorno de Google Cloud, las builds y los despliegues de toda la plataforma quedaron bloqueados mientras se restauraban servicios individuales
- Una vez recuperada toda la infraestructura, se procesó gradualmente un gran backlog de despliegues pendientes para no sobrecargar la plataforma
- Al mismo tiempo, GitHub aplicó rate limiting a las integraciones OAuth y webhook de Railway, lo que bloqueó temporalmente inicios de sesión y builds
- El aumento de llamadas fue resultado de que la caché se vació debido a la caída de Google Cloud
- También se restableció el registro de aceptación de los términos de servicio, por lo que los usuarios tuvieron que aceptarlos nuevamente en su siguiente visita al dashboard
- Railway reconoció su responsabilidad por una decisión de arquitectura que permitió que la acción de un único proveedor ascendente se propagara a una caída general de la plataforma
Cronología del incidente
- 19 de mayo, 22:10 UTC: el monitoreo automático detectó fallas en las comprobaciones de estado de la API y alertó al responsable de guardia
- 19 de mayo, 22:11 UTC: el dashboard comenzó a devolver errores 503 y los usuarios ya no pudieron iniciar sesión
- 19 de mayo, 22:19 UTC: se identificó como causa raíz la suspensión por parte de Google Cloud Platform de la cuenta de producción de Railway
- 19 de mayo, 22:22 UTC: se abrió un ticket P0 con Google Cloud y participó directamente el account manager de GCP de Railway
- 19 de mayo, 22:29 UTC: se declaró el incidente
- 19 de mayo, 22:29 UTC: se restauró el acceso a la cuenta de GCP, pero todas las instancias de cómputo seguían detenidas y los discos persistentes permanecían inaccesibles
- 19 de mayo, 22:35 UTC: las rutas de red en caché comenzaron a expirar y las cargas de trabajo en Railway Metal y AWS empezaron a devolver errores 404
- 19 de mayo, 23:09 UTC: el primer disco persistente volvió a estar en línea
- 19 de mayo, 23:54 UTC: todos los discos persistentes se recuperaron al estado ready, pero la red seguía caída
- 20 de mayo, 00:39 UTC: se confirmó el estado ready de los discos y la recuperación quedó bloqueada por la restauración de la red de Google Cloud
- 20 de mayo, 01:30 UTC: las instancias de cómputo comenzaron a recuperarse
- 20 de mayo, 01:38 UTC: el tráfico de borde volvió a servirse y la red quedó restaurada
- 20 de mayo, 01:57 UTC: se recuperaron la orquestación y la infraestructura de builds, y se pausaron temporalmente los despliegues para evitar que las tareas en espera se ejecutaran todas a la vez y saturaran el sistema
- 20 de mayo, 02:04 UTC: los hosts de cómputo se fueron recuperando gradualmente en línea
- 20 de mayo, 02:47 UTC: GitHub comenzó a aplicar rate limiting a las integraciones OAuth y webhook de Railway, impidiendo que algunos usuarios iniciaran sesión y bloqueando builds
- 20 de mayo, 02:55 UTC: el dashboard volvió a ser accesible
- 20 de mayo, 03:59 UTC: se reanudó nuevamente el procesamiento de despliegues en todos los tiers
- 20 de mayo, 04:00 UTC: se confirmó que la API, el dashboard y los endpoints OAuth estaban funcionando, mientras continuaba la recuperación de las cargas de trabajo restantes
- 20 de mayo, 06:14 UTC: el incidente pasó a fase de monitoreo
- 20 de mayo, 07:58 UTC: el incidente se resolvió
Qué pasó y cómo se recuperó
-
Suspensión de la cuenta de Google Cloud
- El 19 de mayo a las 22:20 UTC, Google Cloud puso por error la cuenta de producción de Railway en estado de suspensión como parte de una acción automatizada
- Esta acción afectó a múltiples cuentas dentro de Google Cloud
- Al tratarse de una medida a nivel de plataforma, no hubo contacto previo con clientes individuales antes de la restricción
- El estado de suspensión deshabilitó la infraestructura relacionada con GCP, incluido Railway Dashboard, la API, parte de la infraestructura de red y capacidad adicional de burst-compute alojada en Google Cloud
-
Dependencia del plano de control
- El plano de control de Railway es el conjunto central de dependencias que sirve el dashboard, procesa builds y despliegues, y llena las tablas de enrutamiento que usa el edge
- Todas las cargas de trabajo en Google Cloud se vieron afectadas de inmediato
- Los proxies de borde de Railway mantenían en caché tablas de enrutamiento del plano de control de red alojado dentro de Google Cloud
- Mientras la caché se mantuvo, las cargas de trabajo en Railway Metal y AWS siguieron atendiendo tráfico
- Cuando expiró la caché, el edge ya no pudo resolver rutas hacia instancias activas, y las cargas de trabajo en todas las regiones, incluidas Metal y AWS, comenzaron a devolver errores 404
- Las cargas de trabajo en sí seguían en línea, pero el impacto de la falla de red se propagó a regiones fuera de Google Cloud
-
Limitaciones del diseño de alta disponibilidad
- La infraestructura de Railway está diseñada con el objetivo de alta disponibilidad, y sus bases de datos se ejecutan en múltiples zonas de disponibilidad, mientras que la red usa enlaces redundantes entre AWS, GCP y Railway Metal
- Incluso después de recuperar el acceso a la cuenta, los servicios individuales no se restauraron automáticamente
- Los discos persistentes, instancias de cómputo y redes requirieron recuperación por separado, y esta característica de recuperación hizo que la caída se prolongara varias horas más
- Los discos se recuperaron al estado ready a las 23:54 UTC, pero la red principal y el enrutamiento de borde no se restauraron por completo hasta aproximadamente las 01:30 UTC del 20 de mayo
- Railway está esperando confirmación sobre si esta demora y los errores relacionados ocurrieron del lado de Google
-
Recuperación gradual e impactos secundarios
- A medida que la red se restauró, se validaron por capas los servicios centrales de Railway y las cargas de trabajo de usuarios finales
- Para evitar sobrecargar el sistema de builds, se pausaron temporalmente los despliegues y luego se reanudaron de manera gradual
- En paralelo con la recuperación de los sistemas centrales, GitHub aplicó rate limiting a las integraciones OAuth y webhook de Railway
- Debido al volumen y la naturaleza en ráfagas de todas las solicitudes de reintento, los inicios de sesión de usuarios y las builds quedaron bloqueados temporalmente
- Hacia las 04:00 UTC del 20 de mayo, se confirmó que la API, el dashboard y los endpoints OAuth estaban funcionando, mientras seguía la recuperación de las cargas de trabajo restantes
Medidas preventivas
-
Diseño de resiliencia existente
- El plano de control de red de Railway está diseñado con una configuración multi-AZ, multi-zone para seguir funcionando sin impacto al usuario incluso si se pierden varias máquinas y componentes
- Este diseño fue probado en staging y con tráfico real antes de su lanzamiento hace algunos meses
- Tras incidentes previos, se había invertido en resiliencia, lo que ya había permitido recuperar de forma estable instalaciones de GitHub de usuarios sin rate limiting secundario
-
Eliminación de una dependencia única
- La red de Railway es un mesh ring compuesto por interconexiones de fibra óptica de alta disponibilidad entre Metal <> GCP <> AWS
- Incluso dentro de ese anillo, seguía existiendo una fuerte dependencia de la API del plano de control de red ejecutándose en máquinas de Google Cloud para descubrir cargas de trabajo
- La malla siguió funcionando durante aproximadamente una hora, pero cuando expiró la caché de rutas falló porque no pudo volver a poblar las tablas de enrutamiento
- Railway ya está trabajando para eliminar de inmediato esta dependencia y convertirla en una mesh real
- El objetivo es que, aunque se caiga cualquier interconexión, siempre quede una ruta entre las nubes
-
Mejoras en bases de datos y failover
- Railway planea expandir sus shards de base de datos de alta disponibilidad a lo largo de AWS y Metal
- A futuro, incluso si todas las instancias de una nube específica desaparecen de inmediato, el quorum de la base de datos deberá mantener el servicio y hacer failover de inmediato de las cargas de trabajo que ya no estén en ejecución
-
Rediseño del plano de datos y del plano de control
- Está en marcha un plan para eliminar los servicios de Google Cloud del hot path del plano de datos y dejarlos solo como opción secundaria o de failover
- Esto avanza en paralelo con la implementación de una nueva arquitectura para el plano de datos que habilita la conectividad de hosts, y para el plano de control que impulsa el dashboard donde los usuarios acceden y administran Railway
- Esta actualización busca asegurar que los servicios centrales, especialmente los componentes orientados al usuario, no dependan de ningún proveedor o plataforma única
Responsabilidad y conclusión
- La responsabilidad por la elección de proveedores recae en Railway, y esta decisión en última instancia también fue responsabilidad de Railway
- A los clientes les importa el producto en sí, no si la causa de la falla fue Google o Railway; el uptime de Railway es responsabilidad de Railway
1 comentarios
Comentarios de Hacker News
La parte interesante y aún no explicada es por qué Google marcó la cuenta
Por más que metieron los timestamps observados en el postmortem, no abordaron la causa raíz
Es muy probable que en la parte de la historia que “no tiene sentido” esté la explicación real que nadie quiere hacer pública todavía
Google nos apagó la cuenta sin aviso previo, y en ese momento gastábamos unos 10 mil dólares al mes
Incluso nos bloquearon la cuenta de soporte premium, así que ni siquiera podíamos avisarle al equipo de soporte que estábamos bloqueados
Unas 8 horas después, algún ingeniero de soporte de Google dijo que era porque estábamos minando bitcoin, lo cual era totalmente absurdo
Teníamos gráficas de uso de CPU y logs de todo el período, y no había ningún pico
Después de unas 12 horas la reactivaron diciendo que había sido un “error de configuración en la detección de abuso”, y nos dieron como 100 dólares en créditos
Digan lo que quieran de AWS, pero AWS no le haría algo así a un cliente sin que antes se comunicara un responsable
Desde entonces no confío en GCP
Los sistemas automatizados se equivocan, pero el problema mayor es que son completamente opacos
Es muy probable que ni Google sepa exactamente cómo funciona ese sistema
Si quieres decir que Railway debería dedicarle esfuerzo a esto en vez de irse de GCP, no veo por qué tendría que hacerlo, a menos que piense demandar a GCP para recuperar el daño a su marca y a la retención de clientes a largo plazo
En cuanto GCP los apagó sin ninguna advertencia previa, para mí ya se acabó; ni siquiera hace falta seguir preguntando
Parece que Railway no ha tenido buena imagen en la prensa tecnológica este mes
En ambos casos, la reputación quedó dañada por procesos automatizados del otro lado
Iba a comentarle al contacto de Google el problema de haber matado Gemini CLI, pero esto me preocupa mucho más
Ellos fueron los únicos que metieron credenciales de una cuenta admin en una IA
Y además no asumieron responsabilidad personal, y eso claramente dañó su reputación
Esta vez al menos sí están reconociendo cierta responsabilidad, así que les doy crédito por mejorar
Además, los problemas de confiabilidad de GCP y el soporte al cliente de Google sí son algo seriamente preocupante
Edit: abajo me enteré de que los dos primeros párrafos estaban mal atribuidos y que fue algo de un cliente de Railway, no de Railway. ¡Perdón, Railway!
Nuestra empresa antes usaba un proveedor de hosting que básicamente añadía algunas garantías extra encima de AWS
Ahora AWS ya ofrece directamente las funciones que necesitábamos, así que terminamos de migrar a AWS normal
Lamentablemente, por esto tuvimos que hacer una migración de emergencia a Azure ayer
Por suerte no teníamos la base de datos en Railway, así que nos recuperamos en unas horas
Me encantaba la simplicidad que ofrecía Railway, pero había demasiados incidentes y limitaciones como para seguir corriendo una app empresarial B2B sobre esa infraestructura
Es un día triste :(
No conozco bien el servicio, pero me pregunto si fue por alguna función única o si básicamente lo usaban como máquinas virtuales
Si fue por funciones únicas, también me gustaría saber qué tan difícil fue la migración de salida
Para herramientas SaaS pequeñas o productos internos, si un equipo no quiere administrar directamente AWS u otro proveedor de IaaS, ¿cuál sería una buena alternativa?
Incluso si usas algo como AWS, si no haces una configuración redundante entre varias zonas de disponibilidad, vas a tener downtime de vez en cuando
Y aunque sí la hagas entre varias zonas de disponibilidad, AWS no está totalmente aislado, así que algunos servicios pueden fallar y aun así haber downtime
Así que acepta el downtime y usa la herramienta que mejor te sirva. Salvo casos tan gravemente malos como GitHub
Si de plano no puedes aceptar nada de downtime, vas a necesitar millones de dólares y meses de trabajo para alcanzar un nivel de confiabilidad que justifique esperar que no haya caídas
Algo del nivel de Chaos Monkey de Netflix y toda esa infraestructura sería suficiente
Como mínimo necesitas dos proveedores con capacidad operativa completa
Puedes llegar bastante lejos incluso sin precios por consumo
Los grandes proveedores cloud ofrecen servicios que son apenas un poco más difíciles que lo que hace Railway, y luego puedes escalar a funciones más avanzadas conforme crecen tus necesidades
Sin añadir un tercero que controle funciones, seguridad y disponibilidad
Por ejemplo, según esta línea de tiempo GCP respondió en 7 minutos
Si hubieran usado Cloud Run, el downtime se habría reducido en más de 7 horas, y si el disparador desconocido estaba relacionado con actividad de otros clientes o con algún comportamiento raro de Railway, probablemente ni siquiera se habrían caído
También está la complejidad
Mucha de la infraestructura compleja que Railway dijo que tuvo que arreglar no habría hecho falta si solo usaran su propia cuenta
Seguro ese código hace cosas útiles, pero para un proveedor de hosting hay muchas piezas móviles que necesita y un usuario normal no
Esta caída tumbó a todos juntos, pero un usuario individual de AWS o de bare metal no se habría visto afectado en principio
No existe una solución óptima global para todos, pero los desarrolladores tienden a subestimar muchísimo los costos directos y los costos menos visibles de trabajar dentro del entorno de otra persona, en comparación con el tiempo que creen ahorrar al saltarse unas cuantas etapas del despliegue
“19 de mayo, 22:10 UTC - El monitoreo automático detectó que falló un health check de la API, activó al on-call y los responsables empezaron a investigar”
“19 de mayo, 22:20 UTC - Google Cloud puso por error la cuenta de producción de Railway en estado suspendido como parte de una acción automatizada”
Si los timestamps son correctos, ¿qué causó el error 10 minutos antes de la suspensión de la cuenta?
La explicación más simple es que uno de los dos timestamps está mal, y eso por sí solo no sería gran cosa
Pero si ni siquiera están seguros de los timestamps, es bastante raro haberlos metido en el reporte como si fueran definitivos cuando se contradicen de forma tan obvia
La sección de la línea de tiempo donde aparece 22:10 es internamente consistente, e incluye también esto
“19 de mayo, 22:19 UTC - Causa raíz identificada: Google Cloud suspendió la cuenta de producción de Railway”
No puedes identificar la causa raíz antes de que ocurra
Por ejemplo, un empleado de Google pudo haber tocado mal alguna configuración y generado una señal que, como en incidentes anteriores, parecía justificar una suspensión, y luego el proceso tardó 10 minutos en convertirse en suspensión real
O un cliente de Railway hizo algo fraudulento o que parecía fraudulento, y el sistema de Google empezó a restringir el acceso y pasó 10 minutos decidiendo si elevarlo a suspensión
Si hubo una persona en el proceso de aprobación, sería aún más plausible
Aunque claramente esa persona no investigó lo suficiente como para ver que no debía hacerse
Esto debería servir de advertencia para cualquiera que opere en GCP
Parece que GCP suspende cuentas por todos lados sin pensar realmente en lo que está haciendo
Como si estuvieran pasando decisiones de producción por Gemini 3.1 Pro
TK tiene historial de arruinar por completo la cultura organizacional, como en OCI, y por lo que he oído hizo algo parecido en GCP
GCP y Google son organizaciones completamente distintas
No esperes calidad de Google solo por el nombre
Es más parecido a una marca vieja que hoy se le pega a productos licenciados baratos, como Nokia. Es exagerado, pero no está tan lejos de la verdad
Además, también se les conoce por cerrar servicios al azar y dar como 6 meses de plazo de migración
Tienen muchos ingenieros sin nada que hacer, así que los ponen a sacar a los usuarios internos de esos servicios, pero la mayoría de los clientes no puede hacer eso
Había un gran texto escrito por un ex empleado de GCP, pero ahora no lo encuentro
Si te tomas tu negocio en serio, evita GCP como a la peste
Edit: irónicamente Gemini sí encontró ese texto. Vale la pena leerlo: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
Tienen el suficiente nombre como para llegar a la parte alta de la portada de HN, y en algún punto deberían poder encontrar a alguien en Google que intervenga
Si hubiera sido un producto pequeño hecho por mí, no habría tenido ningún recurso
La calidad real del producto suele ser buena, lo cual lo hace más triste
Fácilmente podrían haber sido el proveedor número 2, porque Azure es muy inestable y su documentación está por debajo del nivel mínimo
Que GCP sea el número 3 es en gran parte culpa suya
Mi lectura, totalmente no fundamentada, es que llegó a hacer el papel del adulto disciplinado para corregir el enfoque flojo de Google hacia enterprise
Como muestra este incidente, todavía falta mucho, pero quizá era necesario para convertirse en una organización enterprise “seria”
Eso sí, en el proceso puede haber creado una cultura que choca con el resto de Google
Aun así, ¿realmente había una cultura en OCI tan valiosa que pudiera destruirse? En cambio sí parece posible que TK haya traído esa cultura a Google
Nunca los uses para algo importante
No es la primera vez que Google Cloud arruina gravemente cuentas de clientes: https://cloud.google.com/blog/products/infrastructure/detail...
“Railway asume la responsabilidad por la elección de proveedor y, en última instancia, esta elección también es nuestra responsabilidad. A los clientes no les importa si la caída fue culpa de Google o de Railway. Lo que ven es nuestro producto. Su uptime es nuestra responsabilidad, y vamos a seguir garantizándolo”
Es digno de reconocimiento que lo admitan, y no como simple lenguaje de PR
Confiar en GCP fue una falla de arquitectura por parte de Railway, y esto demuestra que están intentando corregirlo
¿Deberían haberlo previsto? Sí. Aun así, mejor tarde que nunca
“Por último, estamos trazando un plan para eliminar los servicios de Google Cloud del hot path del plano de datos y mantenerlos solo para usos auxiliares y de failover”
Bastante claro
Ya no se puede confiar en Google como proveedor de servicios B2B
Hubo una empresa cuya app OAuth de Meta quedó completamente inutilizable solo porque la cuenta personal de Facebook de uno de sus empleados desarrolladores fue bloqueada por Meta sin razón
Escalaron el caso varias veces y no llegaron a ningún lado
Meta es peor porque la cuenta tiene que ser “personal”
Aunque tengas Business Manager, todos los usuarios añadidos allí siguen atados a cuentas personales de Meta/Facebook
Es ridículo
Google ha demostrado muchas veces que no se le puede confiar como proveedor de servicios precisamente por problemas como este
Por eso hay que partirlas en decenas de pedazos
A menudo solo se retractan tarde, después de que el usuario haga pública su indignación y el caso se vuelva viral
Google siempre se ha comportado como si no tuviera ninguna obligación con sus clientes de pago
Creo que esa es la parte más importante
Un proveedor cloud no suspende una cuenta entera sin ningún motivo