Relatório de incidente: 19 de maio de 2026 – Suspensão de conta no GCP
(blog.railway.com)- A indisponibilidade em toda a plataforma Railway durou cerca de 8 horas a partir de 19 de maio de 2026 às 22:20 UTC, e a causa direta foi a suspensão da conta de produção pela Google Cloud
- O dashboard e a API passaram a retornar imediatamente erro 503, e computação, bancos de dados, plano de controle e infraestrutura de burst-compute hospedados na Google Cloud ficaram offline
- As cargas de trabalho em Railway Metal e AWS continuaram em execução, mas o proxy de borda dependia da API do plano de controle hospedada na Google Cloud e, quando o cache de rotas expirou, erros 404 se espalharam
- Após a recuperação do acesso à conta, ainda foi necessário restaurar separadamente discos permanentes, instâncias de computação e rede, e o rate limiting do GitHub em OAuth e webhooks bloqueou ainda mais logins e builds
- A Railway reconheceu a responsabilidade por uma decisão de arquitetura que permitiu que a ação de um único provedor upstream se transformasse em uma falha total, e está redesenhando a arquitetura para remover a Google Cloud do hot path do data plane
Impacto
- De 19 de maio de 2026 às 22:20 UTC até cerca de 20 de maio às 06:14 UTC, a Railway sofreu uma indisponibilidade em toda a plataforma por aproximadamente 8 horas
- Quando a Google Cloud suspendeu o serviço da conta de produção da Railway, a API, o plano de controle, os bancos de dados e a infraestrutura de computação hospedada na Google Cloud ficaram offline
- Os usuários passaram a enfrentar imediatamente erros 503 no dashboard e na API, e não conseguiam fazer login, com mensagens como
"no healthy upstream"e"unconditional drop overload" - Todas as cargas de trabalho hospedadas em computação da Google Cloud ficaram offline
- As próprias cargas de trabalho em Railway Metal e no ambiente burst-cloud da AWS continuaram em execução, mas o proxy de borda da Railway dependia da API do plano de controle hospedada na Google Cloud para preencher as tabelas de roteamento
- Quando as rotas de rede em cache expiraram, cargas de trabalho fora da Google Cloud também ficaram inacessíveis, e o plano de controle de rede passou a retornar erros 404 por não conseguir resolver as rotas das instâncias ativas
- No pico do impacto, as cargas de trabalho da Railway em todas as regiões ficaram inacessíveis
- Durante a recuperação do ambiente da Google Cloud, os builds e deployments em toda a plataforma ficaram bloqueados enquanto serviços individuais eram restaurados
- Após a recuperação de toda a infraestrutura, o grande backlog de deployments pendentes foi processado gradualmente para não sobrecarregar a plataforma
- Ao mesmo tempo, o GitHub aplicou rate limiting às integrações de OAuth e webhook da Railway, bloqueando temporariamente logins e builds
- O aumento no volume de chamadas foi resultado do esvaziamento do cache causado pela falha da Google Cloud
- O registro de aceitação dos termos de serviço também foi redefinido, fazendo com que os usuários precisassem aceitar novamente na próxima visita ao dashboard
- A Railway reconheceu a responsabilidade por uma decisão de arquitetura que permitiu que a ação de um único provedor upstream se propagasse para uma indisponibilidade em toda a plataforma
Linha do tempo do incidente
- 19 de maio, 22:10 UTC: o monitoramento automático detectou falha no health check da API e alertou o responsável de plantão
- 19 de maio, 22:11 UTC: o dashboard passou a retornar erro 503 e os usuários não conseguiam mais fazer login
- 19 de maio, 22:19 UTC: foi identificado que a suspensão da conta de produção da Railway pela Google Cloud Platform era a causa raiz
- 19 de maio, 22:22 UTC: foi aberto um ticket P0 para a Google Cloud, e o gerente de conta GCP da Railway se envolveu diretamente
- 19 de maio, 22:29 UTC: o incidente foi declarado
- 19 de maio, 22:29 UTC: o acesso à conta GCP foi restaurado, mas todas as instâncias de computação continuavam paradas e os discos permanentes permaneciam inacessíveis
- 19 de maio, 22:35 UTC: as rotas de rede em cache começaram a expirar, e as cargas de trabalho em Railway Metal e AWS passaram a retornar erros 404
- 19 de maio, 23:09 UTC: o primeiro disco permanente voltou a ficar online
- 19 de maio, 23:54 UTC: todos os discos permanentes foram restaurados ao estado ready, mas a rede ainda permanecia indisponível
- 20 de maio, 00:39 UTC: o estado ready dos discos foi confirmado, e a recuperação estava bloqueada pela restauração da rede da Google Cloud
- 20 de maio, 01:30 UTC: as instâncias de computação começaram a ser restauradas
- 20 de maio, 01:38 UTC: o tráfego de borda voltou a ser servido, e a rede foi restaurada
- 20 de maio, 01:57 UTC: a infraestrutura de orquestração e build foi restaurada, e os deployments foram pausados temporariamente para evitar que a execução simultânea das tarefas pendentes sobrecarregasse o sistema
- 20 de maio, 02:04 UTC: os hosts de computação foram sendo restaurados gradualmente ao estado online
- 20 de maio, 02:47 UTC: o GitHub começou a aplicar rate limiting às integrações de OAuth e webhook da Railway, impedindo que alguns usuários fizessem login e bloqueando builds
- 20 de maio, 02:55 UTC: o dashboard voltou a ficar acessível
- 20 de maio, 03:59 UTC: o processamento de deployments foi retomado em todos os tiers
- 20 de maio, 04:00 UTC: foi confirmado que a API, o dashboard e os endpoints de OAuth estavam funcionando, enquanto a recuperação das cargas de trabalho restantes continuava
- 20 de maio, 06:14 UTC: o incidente entrou em fase de monitoramento
- 20 de maio, 07:58 UTC: o incidente foi resolvido
O que aconteceu e como a recuperação ocorreu
-
Suspensão da conta Google Cloud
- Em 19 de maio às 22:20 UTC, a Google Cloud colocou por engano a conta de produção da Railway em estado de suspensão como parte de uma ação automatizada
- Essa ação afetou várias contas dentro da Google Cloud
- Como foi uma ação em nível de plataforma, não houve contato prévio com clientes individuais antes da restrição
- O estado de suspensão desativou a infraestrutura relacionada ao GCP, incluindo Railway Dashboard, API, parte da infraestrutura de rede e infraestrutura adicional de burst-compute hospedada na Google Cloud
-
Dependência do plano de controle
- O plano de controle da Railway é o conjunto central de dependências que serve o dashboard, processa builds e deployments e preenche as tabelas de roteamento usadas pela borda
- O impacto foi imediato em todas as cargas de trabalho da Google Cloud
- O proxy de borda da Railway mantém um cache das tabelas de roteamento do plano de controle de rede hospedado dentro da Google Cloud
- Enquanto o cache era mantido, as cargas de trabalho em Railway Metal e AWS continuaram a atender tráfego
- Quando o cache expirou, a borda deixou de conseguir resolver rotas para instâncias ativas, e as cargas de trabalho em todas as regiões, incluindo Metal e AWS, começaram a retornar erros 404
- As próprias cargas de trabalho continuavam online, mas o impacto da falha de rede se espalhou para regiões fora da Google Cloud
-
Limites do design de alta disponibilidade
- A infraestrutura da Railway foi projetada com foco em alta disponibilidade, com bancos de dados executando em múltiplas zonas de disponibilidade e rede usando conexões redundantes entre AWS, GCP e Railway Metal
- Mesmo com a restauração do acesso à conta, os serviços individuais não se recuperaram automaticamente
- Discos permanentes, instâncias de computação e rede precisaram de recuperação separada, e essa característica prolongou o incidente por várias horas
- Os discos foram restaurados ao estado ready às 23:54 UTC, mas a rede crítica e o roteamento de borda não foram totalmente recuperados até cerca de 20 de maio às 01:30 UTC
- A Railway ainda aguarda confirmação se esse atraso e os erros relacionados ocorreram do lado da Google
-
Recuperação gradual e impactos secundários
- Com a restauração da rede, a validação dos serviços principais da Railway e das cargas de trabalho dos usuários finais foi realizada por camadas
- Os deployments foram pausados temporariamente para evitar sobrecarga do sistema de build, e depois retomados gradualmente
- Em paralelo à recuperação dos sistemas centrais, o GitHub aplicou rate limiting às integrações de OAuth e webhook da Railway
- Por causa do volume e do padrão em burst de todas as solicitações de retry, os logins dos usuários e os builds ficaram temporariamente bloqueados
- Por volta de 20 de maio às 04:00 UTC, foi confirmado que a API, o dashboard e os endpoints de OAuth estavam funcionando, enquanto a recuperação das cargas de trabalho restantes continuava
Medidas preventivas
-
Design de resiliência existente
- O plano de controle de rede da Railway foi projetado em uma configuração multi-AZ, multi-zone, capaz de continuar funcionando sem impacto ao usuário mesmo com a perda de várias máquinas e componentes
- Esse design foi testado em staging e com tráfego real antes do lançamento, alguns meses atrás
- Após incidentes anteriores, a empresa vinha investindo em resiliência, e como resultado já havia conseguido restaurar de forma estável as instalações GitHub dos usuários sem rate limiting secundário
-
Remoção de dependência única
- A rede da Railway é um mesh ring composto por interconexões de fibra óptica de alta disponibilidade entre Metal <> GCP <> AWS
- Mesmo dentro desse anel, ainda havia uma forte dependência da capacidade de descoberta das cargas de trabalho atrelada à API do plano de controle de rede executada em máquinas da Google Cloud
- O mesh continuou funcionando por cerca de uma hora, mas falhou quando o cache de rotas expirou e já não foi possível repovoar a tabela de roteamento
- A Railway está trabalhando para remover imediatamente essa dependência e transformá-lo em um mesh de fato
- O objetivo é garantir que, mesmo que qualquer interconexão seja interrompida, sempre reste um caminho entre as nuvens
-
Melhorias em banco de dados e failover
- A Railway pretende expandir shards de banco de dados com alta disponibilidade por AWS e Metal
- No futuro, mesmo que todas as instâncias de uma nuvem específica desapareçam imediatamente, o quorum do banco de dados deverá manter o serviço em operação e acionar failover imediatamente para cargas de trabalho que não estejam mais em execução
-
Redesenho do data plane e do control plane
- Está em andamento um plano para remover os serviços da Google Cloud do hot path do data plane e mantê-los apenas para uso secundário ou de failover
- Isso ocorre em paralelo ao trabalho de implementar uma nova arquitetura para o data plane, que viabiliza a conectividade entre hosts, e para o control plane, que opera o dashboard por meio do qual os usuários acessam e gerenciam a Railway
- Esse upgrade busca garantir que os serviços principais, especialmente os componentes voltados ao usuário, não dependam de um único fornecedor ou plataforma
Responsabilidade e conclusão
- A responsabilidade pela escolha de fornecedor é da Railway, e esta decisão também é, em última instância, responsabilidade da Railway
- Para os clientes, o produto em si importa mais do que se a falha foi culpa da Google ou da Railway, e o uptime da Railway é responsabilidade da Railway
1 comentários
Comentários do Hacker News
A parte interessante e ainda não explicada é por que o Google sinalizou a conta
Não importa quantos timestamps observados coloquem na análise posterior, a causa raiz não foi abordada
É bem possível que a parte da história que “não faz sentido” tenha uma explicação real que ninguém ainda quer tornar pública
O Google desligou nossa conta sem aviso prévio, e na época estávamos gastando cerca de US$ 10 mil por mês
Até a conta de suporte premium ficou bloqueada, então nem conseguimos avisar ao time de suporte que estávamos bloqueados
Depois de umas 8 horas, um engenheiro aleatório de suporte do Google disse que era porque estávamos minerando bitcoin, o que era um completo absurdo
Tínhamos gráficos de uso de CPU e logs de todo o período, e não havia nenhum pico
Depois de umas 12 horas, religaram tudo e disseram que era um “erro de configuração na detecção de abuso”, e nos deram algo como US$ 100 em créditos
Fale o que quiser da AWS, mas a AWS não faria isso com um cliente sem que um responsável entrasse em contato primeiro
Desde então, não confio no GCP
Sistemas automatizados também erram, mas o problema maior é que são completamente opacos
É bem possível que nem o próprio Google saiba exatamente como esse sistema funciona
Se a ideia é dizer que a Railway deveria gastar energia nisso em vez de sair do GCP, não vejo por que faria isso, a menos que pretenda processar o GCP para recuperar o dano à marca e à retenção de clientes no longo prazo
No momento em que o GCP desligou tudo sem qualquer aviso prévio, já era, e nem vejo necessidade de investigar mais
Parece que a Railway teve uma imagem ruim na imprensa técnica este mês
Nos dois casos, a reputação foi prejudicada por procedimentos automatizados do outro lado
Eu ia falar com o responsável do Google sobre o problema que matou o Gemini CLI, mas isto aqui é muito mais preocupante
Só eles colocaram as credenciais da conta de administrador na IA
E também não assumiram responsabilidade pessoal, o que certamente prejudicou a reputação deles
Desta vez pelo menos estão reconhecendo alguma responsabilidade, então dou crédito pela melhora
Além disso, os problemas de confiabilidade do GCP e o suporte ao cliente do Google são realmente graves
Edição: abaixo descobri que os dois primeiros parágrafos foram atribuídos errado e que era algo de um cliente da Railway, não da Railway. Desculpa, Railway!
Nossa empresa usava no passado um hoster que basicamente adicionava algumas garantias extras em cima da AWS
Agora a própria AWS oferece os recursos de que precisávamos, então concluímos a migração para AWS comum
Infelizmente, por causa disso tivemos de fazer uma migração de emergência para o Azure ontem
Felizmente não deixávamos o banco de dados na Railway, então nos recuperamos em poucas horas
A simplicidade que a Railway oferecia era realmente ótima, mas houve incidentes e limitações demais para continuar rodando um app enterprise B2B nessa infraestrutura
Dia triste :(
Não conheço bem o serviço, mas foi por algum recurso único ou era basicamente uso de máquina virtual?
Se foi por algum recurso único, também fico curioso sobre o quão difícil foi a migração de saída
Para pequenas ferramentas SaaS ou produtos internos, se o time não quiser gerenciar diretamente AWS ou outro provedor de IaaS, qual seria uma boa alternativa?
Mesmo usando algo como AWS, se você não tiver redundância em várias zonas de disponibilidade, vai haver downtime de vez em quando
Mesmo com redundância em várias zonas de disponibilidade, a AWS não é totalmente isolada por design, então alguns serviços podem falhar e pode haver downtime
Então aceite o downtime e use as ferramentas que funcionarem melhor para você, exceto em casos tão ruins quanto o GitHub
Se você realmente não pode aceitar nenhum downtime, vai precisar de milhões de dólares e meses de trabalho para chegar a um nível de confiança em que se possa esperar ausência de downtime
O Chaos Monkey da Netflix e a infraestrutura deles provavelmente bastariam
No mínimo você precisa de dois provedores com capacidade operacional completa
Dá para ir bastante longe mesmo sem cobrança por uso
Os grandes provedores de nuvem oferecem serviços que são só um pouco mais difíceis do que o que a Railway faz, e permitem escalar para recursos mais avançados conforme a necessidade aumenta
Você não precisa adicionar um terceiro para controlar funcionalidade, segurança e disponibilidade
Por exemplo, segundo esta linha do tempo, o GCP respondeu em 7 minutos
Se estivessem usando Cloud Run, o downtime teria sido mais de 7 horas menor, e se o gatilho desconhecido estivesse relacionado à atividade de outro cliente ou a algum comportamento estranho da Railway, talvez nem tivesse caído
Também existe complexidade
Boa parte da infraestrutura complexa que a Railway disse que teve de corrigir não teria sido necessária se usasse apenas a própria conta
Esse código certamente faz coisas úteis, mas há muitas peças móveis necessárias para um provedor de hospedagem e desnecessárias para um usuário comum
Este incidente derrubou todo mundo junto, mas usuários individuais de AWS ou bare metal originalmente não teriam sido afetados
Não existe uma solução global ideal para todos, mas desenvolvedores tendem a subestimar fortemente os custos diretos e os custos menos visíveis de trabalhar dentro do ambiente de outra pessoa em comparação com o tempo economizado ao reduzir algumas etapas de deploy
“19 de maio, 22:10 UTC - o monitoramento automático detectou falha nas verificações de status da API, acionou o plantão e os responsáveis iniciaram a investigação”
“19 de maio, 22:20 UTC - o Google Cloud colocou por engano a conta de produção da Railway em estado de suspensão como parte de uma ação automática”
Se os timestamps estiverem corretos, então o que causou o erro 10 minutos antes da suspensão da conta?
A explicação mais simples é que um dos dois timestamps está errado, e isso por si só não é grave
Mas se eles não têm certeza dos timestamps, é bem estranho terem colocado isso no relatório como algo confirmado, mesmo sendo claramente contraditório
A seção de linha do tempo em que aparece 22:10 é internamente consistente e inclui também o seguinte
“19 de maio, 22:19 UTC - causa raiz identificada: o Google Cloud Platform suspendeu a conta de produção da Railway”
Não dá para identificar a causa raiz antes de ela acontecer
Por exemplo, um funcionário do Google pode ter mexido em uma configuração errada e criado um sinal que parecia exigir suspensão, como em incidentes anteriores, e o processo até a suspensão pode ter levado 10 minutos
Ou um cliente da Railway pode ter feito algo fraudulento ou que parecia fraudulento, e o sistema do Google pode ter iniciado restrições de acesso e passado 10 minutos decidindo se elevaria isso a uma suspensão
Se houve aprovação humana no processo, isso fica ainda mais plausível
Só que claramente essa pessoa não investigou o suficiente para ver que não deveria fazer isso
Isso deveria servir de alerta para qualquer um operando no GCP
O GCP parece suspender contas para todo lado sem nem pensar no que está fazendo
Parece que tomam decisões de produção com o Gemini 3.1 Pro
TK tem histórico de destruir totalmente a cultura organizacional, como no OCI, e pelo que ouvi parece ter feito algo parecido no GCP
GCP e Google são organizações completamente diferentes
Não espere qualidade do Google só por causa do nome
É parecido com a Nokia, um nome antigo que hoje vai em produtos licenciados e baratos. É exagero, mas não está longe da verdade
Além disso, também é conhecida por encerrar serviços aleatoriamente e dar algo como 6 meses de prazo de migração
Há muitos engenheiros sem ter o que fazer, então eles os colocam para tirar usuários internos desses serviços, mas a maioria dos clientes não consegue fazer o mesmo
Havia um excelente texto escrito por um ex-funcionário do GCP, mas não consigo encontrá-lo agora
Se você leva seu negócio a sério, evite o GCP como se fosse uma praga
Edição: ironicamente, o Gemini encontrou o texto. Vale a leitura: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
Tem nome suficiente para chegar ao topo da página principal do HN, e em algum momento deve ter escala suficiente para encontrar alguém no Google que possa intervir
Se fosse um produto pequeno feito por mim, eu não teria recurso nenhum
A qualidade real dos produtos é boa, o que torna isso ainda mais triste
Poderia facilmente ter sido o provedor nº 2, porque o Azure é extremamente instável e a documentação é de baixo nível
O fato de o GCP ser o nº 3 é em grande parte culpa dele mesmo
Minha avaliação totalmente sem base é que ele entrou como o adulto disciplinado para corrigir a abordagem frouxa do Google ao enterprise
Como este incidente mostra, ainda falta muito, mas talvez isso fosse necessário para se tornar uma organização enterprise “séria”
Mesmo assim, pode ter criado no processo uma cultura em choque com o resto do Google
Dito isso, será que a divisão da Oracle chamada OCI tinha mesmo alguma cultura para destruir? Em vez disso, parece possível que TK tenha levado essa cultura para o Google
Nunca devem ser usados para nada importante
Não é a primeira vez que o Google Cloud prejudica seriamente contas de clientes: https://cloud.google.com/blog/products/infrastructure/detail...
“A Railway assume a responsabilidade pela escolha do fornecedor e, no fim das contas, essa escolha também é nossa responsabilidade. Os clientes não se importam se a falha foi do Google ou da Railway. O que os clientes veem é o nosso produto. O uptime de vocês é nossa responsabilidade, e continuaremos a entregá-lo”
É digno de elogio reconhecer isso, e não apenas com linguagem de PR
Confiar no GCP foi uma falha de arquitetura por parte da Railway, e isso mostra que estão tentando corrigir
Deveriam ter previsto isso? Sim. Ainda assim, é melhor fazer tarde do que não fazer
“Por fim, estamos planejando remover os serviços do Google Cloud do caminho crítico do data plane e mantê-los apenas para uso secundário/failover”
É bem claro
Não dá mais para confiar no Google como provedor de serviços B2B
Em uma empresa, o app OAuth da Meta ficou completamente inutilizável só porque a conta pessoal de Facebook de um funcionário desenvolvedor foi bloqueada pela Meta sem motivo
Escalaram isso várias vezes, mas não chegaram a lugar nenhum
A Meta é pior porque a conta precisa ser “pessoal”
Mesmo com o Business Manager, todos os usuários adicionados ali continuam vinculados a contas pessoais Meta/Facebook
É ridículo
O Google já provou várias vezes que não dá para confiar nele como provedor de serviços exatamente por esse tipo de problema
Por isso precisam ser quebradas em dezenas de pedaços
Frequentemente só volta atrás muito depois, quando o usuário torna a indignação pública e o caso ganha repercussão
O Google sempre agiu como se não tivesse obrigação nenhuma com clientes pagantes
Na minha opinião, essa é a parte mais importante
Um provedor de nuvem não suspende uma conta inteira sem motivo