开发者部署平台 Railway 称，Google Cloud 在一次自动化操作中错误暂停其生产账号，导致 Railway 出现约 8 小时平台级故障，影响范围从 GCP 扩散到 Railway Metal 和 AWS 环境。
2026 年 5 月 20 日，Railway 发布事故报告称，5 月 19 日 22:20 UTC 至 5 月 20 日约 06:14 UTC，经历了一次平台级服务中断，持续约 8 小时。
Railway 称，故障原因是 Google Cloud 错误将其生产账号置于暂停状态，导致其托管在 GCP 上的基础设施短暂失去服务。
Railway 是一家面向开发者的应用部署平台，主要帮助用户从 GitHub 代码库自动完成云端部署。
《The Register》报道称，Railway 每年在 Google Cloud 上的支出超过 1000 万美元（6805 万元人民币），但这次账号暂停仍“毫无预警”发生。
Railway 的解决方案工程师 Angelo Saraceno 表示，该公司在 22:00 UTC 前后发现了问题。他说，该公司的资源似乎被删除了，完全消失了。谷歌随后解释道，它暂停了 Railway 的帐户，导致其资源不可见。
他补充道：“在谷歌负责与我们对接的联系人感到困惑，客户们非常愤怒。”
颇具讽刺意味的是，在 2024 年，Railway 决定将其大部分基础设施迁移到托管服务，此前谷歌“造成了一大堆问题，对我们的业务构成了事关存亡的威胁”。
然而在 2025 年，谷歌云再次出现问题，Railway 的服务再次受到影响，这些问题又浮出水面。
但 Railway 仍然将其控制平面留在谷歌云上，仍然依赖运行在谷歌云端的数据库。这些资源使得该公司每年在谷歌云上花费数千万美元。
然而 Saraceno 表示，当此次事件发生时，谷歌的支持团队一个小时后才介入。
“我们非常愤怒，目前仍在努力了解所有细节，“他说道，随后提出了一种说法，认为 Railway 可能触发了某项强制执行规则。
这次故障最初影响 Railway 的 Dashboard、API、控制面、数据库，以及部署在 Google Cloud 上的计算资源。
用户很快遇到 503 错误，提示包括 “no healthy upstream” 和 “unconditional drop overload”，同时出现登录失败、无法访问控制台等问题。
所有托管在 Google Cloud compute 上的工作负载也被下线。
更严重的是，故障没有停留在 GCP 内部。
Railway 称，其自有 Railway Metal 和 AWS burst-cloud 环境中的工作负载一开始仍在运行，但 Railway 的边缘代理依赖托管在 Google Cloud 上的控制面 API 来填充路由表。
随着缓存路由过期，Metal 和 AWS 上的工作负载也开始无法解析，返回 404。事故高峰期，Railway 所有区域的工作负载均变得不可访问。
Railway 的时间线显示：
5 月 19 日 22:10 UTC，自动监控发现 API 健康检查失败；
22:19，团队确认根因是 Google Cloud 暂停了 Railway 的生产账号；
22:22，Railway 向 Google Cloud 提交 P0 工单，并联系 GCP 账号经理；
22:29，账号访问恢复，但计算实例仍处于停止状态，持久磁盘也不可访问。
账号恢复并不等于服务恢复，后续还需要逐层恢复磁盘、网络、计算实例和边缘流量。
根据 Railway 的说法，这次暂停来自 Google Cloud 的一次错误自动化动作，并且影响了 Google Cloud 内部的多个账号。
Railway 称，由于这是一次平台级动作，个别客户在限制生效前没有收到主动通知。
Railway 还表示，恢复过程被拉长的原因之一，是持久磁盘、计算实例和网络都需要分别恢复，而不是账号访问恢复后自动全部恢复。
事故恢复过程中还出现了二次影响。
Railway 称，由于 GCP 故障清空了部分缓存，Railway 对 GitHub OAuth 和 webhook 的请求量短时间内激增，随后遭到 GitHub 限流，导致部分用户继续无法登录，构建也受到阻碍。
Railway 还一度暂停部署，以避免大量排队任务同时执行后再次压垮系统。
Railway 在事故报告中承认，虽然外部触发点来自 Google Cloud，但公司仍需为自身架构选择负责。Railway 计划立即移除网络控制面对 GCP 的硬依赖，扩展高可用数据库分片至 AWS 和 Railway Metal，并将 Google Cloud 服务从数据平面的关键路径中移出，仅保留为次级或故障转移用途。
一个年花费超过 1000 万美元的客户，在关键基础设施仍依赖单一上游控制面时，依然可能被一次自动化账号动作拖入全平台故障。对 Railway 来说，问题已经不只是多云部署，而是控制面、路由发现和数据库仲裁是否真正摆脱单点依赖。
