Como uma restrição de conta no Google Cloud provocou o grande apagão do Railway em 19 de maio

No fim de maio, a plataforma de desenvolvimento Railway sofreu uma grande interrupção que deixou dashboards, APIs, deploys e aplicações hospedadas inacessíveis por horas. A origem do problema foi inesperada: o Google Cloud colocou automaticamente a conta de produção do Railway em um estado de restrição, o que removeu acesso a componentes críticos da infraestrutura.

Embora os serviços tenham sido restaurados posteriormente, o episódio expôs um risco estrutural comum em plataformas modernas: a dependência profunda de um único provedor de nuvem, mesmo quando a arquitetura parece distribuída.

Linha do tempo da falha

A interrupção começou por volta de 22:20–22:29 UTC em 19 de maio, quando sistemas do Railway perderam acesso a recursos essenciais hospedados no Google Cloud. Usuários rapidamente relataram problemas generalizados: dashboards não carregavam, logins falhavam e aplicações implantadas retornavam erros de upstream.

Engenheiros da própria plataforma informaram depois que a conta do Railway no Google Cloud havia sido colocada em estado “restricted”, o que resultou na remoção automática de vários recursos vinculados a essa conta.

A recuperação levou horas. A equipe precisou trabalhar diretamente com o suporte do Google Cloud para restaurar o acesso à conta e reativar os serviços afetados. Mesmo com representantes dedicados e suporte empresarial, relatos indicam que levou tempo para identificar o motivo da restrição e reverter o bloqueio.

Por que serviços essenciais caíram imediatamente

A restrição afetou componentes usados tanto por cargas de trabalho dos clientes quanto pelos próprios sistemas internos do Railway.

De acordo com atualizações da empresa, vários elementos críticos desapareceram ao mesmo tempo:

• CloudSQL, onde estavam armazenados dados da plataforma
• A API do Railway, dependência central de vários serviços
• VMs de overflow, usadas para capacidade extra de computação

Quando a API foi removida, uma dependência central do plano de controle da plataforma deixou de existir, quebrando diversos sistemas que dependiam dela.

Sem esses componentes, o Railway não conseguia operar de forma confiável:

• o dashboard e o sistema de login
• fluxos de deploy
• roteamento de aplicações
• builds e provisionamento de novas cargas

Por isso, tanto a interface para desenvolvedores quanto as aplicações hospedadas ficaram instáveis ou inacessíveis durante a janela da falha.

Como a falha se espalhou pela plataforma

O impacto não ficou limitado aos recursos inicialmente removidos porque as camadas de orquestração e roteamento dependiam desses serviços.

Engenheiros do Railway indicaram que, em muitos casos, a recuperação exigia que usuários fizessem redeploy de suas aplicações, permitindo que o sistema direcionasse o código para máquinas saudáveis quando partes da infraestrutura voltavam a funcionar.

Isso sugere que o plano de controle responsável por agendamento, roteamento e reconstrução de workloads não conseguia se recuperar automaticamente enquanto recursos importantes do Google Cloud permaneciam inacessíveis.

Algumas análises da comunidade sugeriram que o problema também atingiu workloads executados fora do Google Cloud — por exemplo, em AWS ou hardware próprio do Railway — porque o estado de roteamento da plataforma não podia ser atualizado corretamente. Porém, o mecanismo técnico exato desse efeito em cascata ainda não foi confirmado em um post‑mortem completo.

O alerta sobre “multi‑cloud”

Um dos pontos mais discutidos após o incidente foi a lição arquitetural que ele deixou.

O Railway opera infraestrutura em múltiplos ambientes, incluindo AWS e hardware dedicado. Ainda assim, a interrupção mostrou que a verdadeira resiliência depende de onde está o plano de controle.

Se elementos como orquestração, identidade, roteamento ou bancos de dados dependem de uma única conta de provedor, essa conta se torna efetivamente um ponto único de falha.

Quando o acesso foi perdido, não desapareceram apenas recursos de computação. Também ficaram indisponíveis sistemas que:

• rastreiam deploys
• gerenciam rotas
• provisionam infraestrutura
• recuperam workloads

Essa dependência permitiu que um único evento de restrição se propagasse por toda a plataforma.

Debate sobre automação nos provedores de nuvem

O episódio também reacendeu discussões sobre mecanismos automáticos de fiscalização usados por grandes provedores de nuvem.

Plataformas como Google Cloud podem restringir ou suspender contas automaticamente em resposta a sinais como problemas de cobrança, violações de política ou riscos de segurança. No caso do Railway, porém, o gatilho específico da restrição não foi confirmado publicamente, o que deixou dúvidas sobre se a ação foi automática, um erro ou outro problema operacional.

O incidente destacou dois riscos operacionais importantes:

• Ações automáticas podem desativar infraestrutura crítica instantaneamente.
• Mesmo clientes com suporte empresarial podem enfrentar demora até que a causa do bloqueio seja investigada.

O que ainda não está claro

Apesar das atualizações do Railway e das discussões na comunidade, algumas informações continuam sem confirmação pública:

• O motivo exato da restrição da conta no Google Cloud
• O mapa completo de dependências internas entre CloudSQL, APIs, roteamento e infraestrutura
• Se certos efeitos em cascata foram confirmados internamente ou apenas inferidos por observadores

Até que um post‑mortem técnico detalhado seja publicado, parte da explicação pública permanece baseada em reconstruções feitas a partir de atualizações da empresa e relatos da comunidade.

A lição para plataformas de nuvem

O apagão de 19 de maio no Railway reforça uma realidade importante da infraestrutura moderna: dependências do plano de controle podem ser mais críticas que a diversidade de infraestrutura.

Executar workloads em múltiplas nuvens não garante resiliência se os sistemas responsáveis por deploy, roteamento e orquestração ainda dependem de uma única conta de provedor. Quando esse núcleo desaparece — mesmo que temporariamente — toda a plataforma pode ficar offline.