Reporte del incidente: Railway bloqueado por Google Cloud [resuelto]

 (status.railway.com)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • La interrupción generalizada del servicio de Railway ya fue resuelta, y se confirmó que la causa fue el bloqueo de la cuenta de Google Cloud de Railway
  • Durante la interrupción, los usuarios pudieron experimentar "no healthy upstream", "unconditional drop overload", fallas de inicio de sesión y falta de acceso al panel
  • Railway se comunicó directamente con el equipo de soporte de Google Cloud para restaurar el acceso a la cuenta y avanzar con la recuperación del plano de control y de las cargas de trabajo
  • Durante la recuperación, persistieron problemas de red en Google Cloud que impidieron el arranque de algunos servicios, y las compilaciones no empresariales se limitaron temporalmente
  • El servicio ya se recuperó por completo, pero algunas cargas de trabajo detectadas como anómalas se están redesplegando automáticamente y, si hace falta, los usuarios deberán redesplegarlas manualmente

Resumen de la interrupción y estado final

  • Railway resolvió una interrupción generalizada del servicio, y el análisis posterior puede consultarse en Incident Report
  • Durante la interrupción, los usuarios pudieron experimentar "no healthy upstream", "unconditional drop overload", fallas de inicio de sesión y falta de acceso al panel
  • La causa fue el bloqueo de la cuenta de Google Cloud de Railway, lo que dejó algunos servicios de Railway fuera de disponibilidad
  • Railway se comunicó directamente con el equipo de soporte de Google Cloud para restaurar el acceso a la cuenta y avanzar con la recuperación de las cargas de trabajo
  • El servicio ya se recuperó por completo, pero algunas cargas de trabajo detectadas en estado anómalo se están redesplegando automáticamente, y es posible que los usuarios deban redesplegar manualmente los servicios que no estén respondiendo con normalidad

Progreso de la recuperación e impacto para los usuarios

  • Investigación inicial y confirmación de la causa

    • Railway restauró la infraestructura de Google Cloud que opera el plano de control del panel, la API y la red interna
    • Incluso después de restablecer el acceso al proveedor de nube principal, el panel de Railway y los servicios que corrían sobre la infraestructura en la nube pudieron seguir afectados hasta que se aplicaron despliegues correctivos
    • Tras el bloqueo de la cuenta de Google Cloud, el equipo de plataforma de Railway verificó el acceso a parte de la infraestructura alojada en Google Cloud y restauró el acceso al resto de los servicios

  • Google Cloud y problemas de red

    • Railway recuperó el cómputo en Google Cloud, pero persistieron problemas de red del lado de Google Cloud que impidieron que algunos servicios arrancaran
    • Durante la recuperación, las cargas de trabajo alojadas en Google Cloud pudieron seguir experimentando problemas intermitentes
    • El equipo de infraestructura de Railway también evaluó rutas alternativas para volver a poner en línea los servicios afectados

  • Restricciones en compilaciones y despliegues

    • Las cargas de trabajo en metal de Railway comenzaron a recuperarse gradualmente
    • Durante la recuperación, todas las compilaciones no empresariales se limitaron temporalmente para evitar una sobrecarga de la infraestructura de compilación
    • Después, los despliegues no empresariales permanecieron suspendidos temporalmente, mientras que los despliegues empresariales no se vieron afectados
    • Incluso después de que los despliegues volvieron a estar disponibles, las cargas de trabajo que seguían en Google Cloud pudieron continuar con problemas intermitentes hasta que terminara la recuperación

  • Medidas actuales

    • Los servicios de Railway ya se recuperaron por completo, y los servicios que no respondan con normalidad deben redesplegarse desde el panel o la CLI
    • Se puede consultar más contexto en el FAQ, y si se necesita soporte directo, se puede abrir un hilo en Railway Station

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Comentarios de Hacker News

  • Railway resolvió esta caída y publicó el análisis posterior
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    Al 20 de mayo, 07:57 UTC, también publicaron la página de estado
    https://status.railway.com/incident/I23M92U0

    • Creo que en casos así debería ser posible exigir una indemnización a Google. No es el tipo de problema que uno esperaría ver cubierto por los términos, como una caída de red o una falla del servicio
    • Railway dice que la caída ya se resolvió, pero muchos servicios siguen caídos y devuelven 502. En nuestro caso solo se recuperó después de activar manualmente un redespliegue, y creo que Railway debió haberlo hecho automáticamente
      En total, nuestro tiempo de inactividad fue de más de 11 horas

  • Van 0 días desde que GCP volvió a tumbar a una startup
    Siento que esto pasa por lo menos una vez al año, y nunca he oído algo así de AWS o Azure
    Hablando en serio, por eso no uso GCP. De las tres grandes, es la nube más agradable de usar, pero se sabotea sola con esta reputación

    • En cambio, no recuerdo una caída grave de GCP. AWS/Azure parecen tener caídas catastróficas varias veces al año
    • AWS lo hace con más eficiencia. Si se cae us-east-1, tumba a varias startups de una sola vez
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azure también rompió el año pasado la front door de todos los servicios de Azure y O365
      Cada una de estas empresas tiene áreas en las que es buena, pero a veces fallan a lo grande
    • Una vez AWS nos hizo tanto throttling que era imposible operar nuestro servicio. Quise escribir sobre cómo detuvieron nuestro crecimiento por un mes, pero ahora ya no parece tan relevante
    • Nosotros tampoco tocamos GCP por la misma razón

  • Todos quieren culpar a Google, pero como alguien que ha usado Railway por bastante tiempo, me gustaría escuchar también la versión de GCP antes de sacar conclusiones. Railway ya ha tenido problemas como este antes, y la forma en que su equipo los maneja no inspira confianza
    De cualquier modo, esto fue el colmo para mí

    • Yo también estoy de acuerdo, aunque sea anecdótico. El equipo de desarrollo de Railway da la impresión de moverse con bastante soltura, mezclando vibe coding por todos lados. Hay un nivel aceptable de “todavía somos una startup, téngannos paciencia”, y Railway ya se pasó de esa línea
    • Sí. En otros hilos se ven muchas cuentas criticando con dureza al proveedor de nube, pero es raro que en toda esta corriente de enojo casi nadie parezca interesado en el origen del problema ni en evaluar esa posibilidad
    • Hace 2 años necesité soporte y fue tan pésimo que simplemente me cambié a Vercel y les dije que se fueran al diablo
      Buscando algo parecido para otros servicios descubrí coolify. Si puedes usar coolify, no hay absolutamente ninguna razón para usar Railway
    • Si puedes contar algún caso concreto del pasado, me gustaría leerlo
    • Escuché detalles que no debería conocer. Puedo decir con confianza que esto fue 100% culpa de Google, y me decepcionaría si Railway no pudiera compartir más
      De verdad no había forma de que Railway lo evitara, salvo no usar GCP en absoluto

  • También estuvo la caída de UniSuper en mayo de 2024: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    Según la declaración conjunta del CEO de UniSuper, Peter Chun, y el CEO de Google Cloud, Thomas Kurian, durante el aprovisionamiento del servicio Private Cloud de UniSuper ocurrió un error de configuración por descuido, y eso terminó eliminando la suscripción de Private Cloud de UniSuper
    Google Cloud dijo que fue un incidente aislado y “único en su tipo”, sin precedentes para ningún cliente de Google Cloud en el mundo, pero esa eliminación de la suscripción provocó la eliminación en ambas regiones, y la recuperación requirió restaurar cientos de máquinas virtuales, bases de datos y aplicaciones

    • Escribí sobre el problema de UniSuper en ese momento: https://danielcompton.net/google-cloud-unisuper
      Fue un bug bastante grave, y su entorno de VMWare se creó con una fecha de vencimiento de 1 año, pero desde la perspectiva de Google Cloud era un solo “recurso”
    • Que “la eliminación de la suscripción de Private Cloud provocó la eliminación en ambas regiones” es lo que se llama un punto único de falla, y cualquiera que haya tenido responsabilidad sobre seguridad lo vería como una pesadilla
    • Un diseño donde cerrar o borrar una suscripción desencadena eliminaciones en cadena a nivel global suena como una receta para el desastre. No entiendo por qué no la marcan solo para borrado y la eliminan un día o una semana después

  • No entiendo cómo puede pasar algo así en una empresa con una factura mensual tan alta. En mi trabajo anterior, cuando se ejecutaba una carga sospechosa en AWS, el TAM nos contactaba antes de tomar medidas
    En este caso, imagino que fue alguna automatización de IA defectuosa, y como a GCP parece no gustarle contactar a una persona real y obtener una respuesta, tal vez algún contratista externo lo vio horas después en la cola de soporte y solo envió una respuesta enlatada

    • Si se trata de soporte de GCP, ya nada me sorprende. Hemos tenido más de 12 Account Executive distintos en los últimos 6 años, aunque no los necesitamos para nada, y todos han sido completamente inútiles
      Cada vez se presentaban, pedían agendar reuniones con el equipo de ingeniería, llegaban con un deck de diapositivas genéricas que no tenía absolutamente nada que ver con nosotros y solo daba risa, y la siguiente vez que sabíamos algo era cuando nos asignaban otro AE nuevo
      Me gusta GCP y sus servicios, y he estado satisfecho con ellos durante años, pero la parte humana es realmente pésima y no entiendo para qué la mantienen
    • Creo que también hubo una respuesta útil en otro hilo. Nosotros recuperamos la cuenta, pero incluso con Account Rep y CSM tomó tiempo entender qué había pasado
      Sin esos contactos, podría haber sido peor
    • Porque es Google. Te deja usar el servicio, pero en cuanto te sales de la norma, te suspende

  • Como alguien que opera una API pública, la cantidad de spam que llega desde IPs de Railway es absurda. La prevención de abuso es pésima, y ojalá esto sirva para mejorar sus operaciones

    • Cuando operas una empresa de hosting, ese es exactamente el conflicto central. Si haces fácil el registro, llegan muchos usuarios nuevos, pero también entra mucho abuso
      Si pones medidas antiabuso, aparecen falsos positivos escandalosos, y este caso de GCP podría ser uno de ellos
      No envidio a quien opera una empresa de hosting. Internet es realmente sucio bajo la superficie
      Dicho eso, AWS hace esto muy bien. Supongo que gracias a unos 30 años de experiencia enfrentando fraude y abuso en retail

  • Espera, ¿Railway corría sobre GCP? ¿No decían con bombo y platillo que “no construimos una nube sobre otra nube”?
    ¿O querían decir que no alquilan VPS, sino solo bare metal de un proveedor de nube?
    Al menos yo me ilusioné pensando que había surgido otro proveedor que hacía colocación y era dueño de más partes del stack, en vez de simplemente pagarle a uno de los hyperscalers
    https://blog.railway.com/p/heroku-walked-railway-run

    • El artículo enlazado, visto en Wayback Machine, decía esto
      “Desde el primer día mantuvimos esta idea al frente.
      También intuimos que no se puede construir una nube sobre otra nube. Hemos dedicado años a operar nuestros propios servidores y a la práctica de convivir bien con otras nubes para que el negocio de Railway, y en última instancia el de nuestros clientes, sea lo más sólido posible.”
    • Sí, y por eso da coraje. Mintieron. Dependían totalmente de GCP
      Ahora voy a tener que investigar un poco. Necesito algo más estable y menos dependiente del capricho de una sola empresa
      También es malo para Railway, porque esto golpea justo el núcleo de su gran promesa de despliegue de software pacífico. Esto es caos

  • Pensé que Railway estaba construyendo sus propios centros de datos [0]
    “En la práctica, no se puede construir una nube sobre la nube de otra persona.”
    Pues sí que resultó ser verdad…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel parece lograrlo. PlanetScale también, al menos en la parte de bases de datos, y al final todo es base de datos

  • Cuando te registras en Railway, es curioso cómo te hacen confirmar que leíste y entendiste los términos sobre abuso del sistema, minería de criptomonedas, etc.
    Mi suposición es que muchos usuarios abusan del free tier y eso les genera problemas con sus proveedores de servicio
    Incluso como competidor, no me alegra ver que Railway reciba un golpe así, pero el cómputo gratuito atrae a toda clase de usuarios raros. Nosotros también lo vivimos y decidimos evitar el cómputo gratuito al principio, aunque eso redujera la parte alta del embudo

  • Creo que es difícil culpar solo a Google. Railway parece estar teniendo cada vez más problemas para mantener la estabilidad de la plataforma
    Algo así no debería tumbar todo el servicio. Si tu negocio es literalmente proveer un backend estable, deberías tener respaldos. A mis ojos, esto parece una planificación deficiente

    • No entiendo bien a qué te refieres. ¿De verdad esperas que Railway use una arquitectura multicloud para alojar todos los proyectos de sus clientes? Viéndolo en conjunto, eso probablemente reduciría la disponibilidad
    • ¿La recuperación ante desastres no es bastante cara? Especialmente a la escala de Railway, suena todavía más probable