Rapport d’incident : 19 mai 2026 – suspension du compte GCP
(blog.railway.com)- Une panne généralisée de la plateforme Railway a duré environ 8 heures à partir du 19 mai 2026 à 22:20 UTC, avec pour cause directe la suspension du compte de production chez Google Cloud
- Le dashboard et l’API ont immédiatement renvoyé des erreurs 503, et les infrastructures de calcul, de base de données, de control plane et de burst-compute hébergées sur Google Cloud sont passées hors ligne
- Les workloads sur Railway Metal et AWS ont continué à s’exécuter, mais le proxy edge dépendait de l’API du control plane sur Google Cloud ; après l’expiration du cache de routes, les erreurs 404 se sont propagées
- Même après le rétablissement de l’accès au compte, les disques persistants, instances de calcul et le réseau ont dû être restaurés séparément, tandis que la limitation de débit sur GitHub OAuth et les webhooks a en plus bloqué les connexions et les builds
- Railway reconnaît sa responsabilité dans des choix d’architecture qui ont permis à l’action d’un fournisseur amont unique de provoquer une panne globale, et travaille à une refonte visant à retirer Google Cloud du hot path du data plane
Impact
- Une panne généralisée de la plateforme Railway s’est produite pendant environ 8 heures, du 19 mai 2026 à 22:20 UTC jusqu’au 20 mai vers 06:14 UTC
- Après la suspension par Google Cloud des services du compte de production de Railway, l’API, le control plane, les bases de données et l’infrastructure de calcul hébergée sur Google Cloud sont passés hors ligne
- Les utilisateurs ont immédiatement subi des erreurs 503 sur le dashboard et l’API, avec impossibilité de se connecter et des messages
"no healthy upstream"et"unconditional drop overload" - Tous les workloads hébergés sur les ressources de calcul Google Cloud sont passés hors ligne
- Les workloads sur Railway Metal et dans l’environnement burst-cloud AWS ont continué à s’exécuter, mais le proxy edge de Railway dépendait d’une API du control plane hébergée sur Google Cloud pour alimenter ses tables de routage
- Une fois les routes réseau mises en cache expirées, les workloads hors de Google Cloud sont eux aussi devenus injoignables, le control plane réseau ne pouvant plus résoudre les routes des instances actives et renvoyant des erreurs 404
- Au plus fort de l’impact, les workloads Railway de toutes les régions étaient inaccessibles
- Pendant la restauration de l’environnement Google Cloud, les builds et déploiements de toute la plateforme ont été bloqués le temps de rétablir les services un par un
- Une fois l’ensemble de l’infrastructure restauré, un important backlog de déploiements en attente a été traité progressivement afin d’éviter de surcharger la plateforme
- En parallèle, GitHub a appliqué une limitation de débit aux intégrations OAuth et webhook de Railway, bloquant temporairement les connexions et les builds
- Cette hausse du volume d’appels résultait de la vidange des caches provoquée par la panne Google Cloud
- L’enregistrement de l’acceptation des conditions d’utilisation a également été réinitialisé, obligeant les utilisateurs à accepter de nouveau lors de leur prochaine visite du dashboard
- Railway reconnaît sa responsabilité dans les choix d’architecture qui ont permis à l’action d’un fournisseur amont unique de se transformer en panne générale de la plateforme
Chronologie de l’incident
- 19 mai 22:10 UTC : la supervision automatisée détecte l’échec des checks de santé de l’API et alerte l’astreinte
- 19 mai 22:11 UTC : le dashboard renvoie des erreurs 503 et les utilisateurs ne peuvent plus se connecter
- 19 mai 22:19 UTC : la suspension par Google Cloud Platform du compte de production de Railway est identifiée comme cause racine
- 19 mai 22:22 UTC : un ticket P0 est ouvert auprès de Google Cloud et l’account manager GCP de Railway s’implique directement
- 19 mai 22:29 UTC : l’incident est déclaré
- 19 mai 22:29 UTC : l’accès au compte GCP est rétabli, mais toutes les instances de calcul restent arrêtées et les disques persistants sont inaccessibles
- 19 mai 22:35 UTC : les routes réseau mises en cache commencent à expirer, et les workloads Railway Metal et AWS renvoient des erreurs 404
- 19 mai 23:09 UTC : le premier disque persistant revient en ligne
- 19 mai 23:54 UTC : tous les disques persistants sont revenus à l’état ready, mais le réseau reste indisponible
- 20 mai 00:39 UTC : l’état ready des disques est confirmé, mais la restauration reste bloquée par celle du réseau Google Cloud
- 20 mai 01:30 UTC : les instances de calcul commencent à être restaurées
- 20 mai 01:38 UTC : le trafic edge recommence à être servi et le réseau est rétabli
- 20 mai 01:57 UTC : l’infrastructure d’orchestration et de build est restaurée ; les déploiements sont temporairement suspendus pour éviter que l’exécution simultanée des tâches en attente ne sature le système
- 20 mai 02:04 UTC : les hôtes de calcul reviennent progressivement en ligne
- 20 mai 02:47 UTC : GitHub commence à limiter le débit des intégrations OAuth et webhook de Railway, empêchant certains utilisateurs de se connecter et bloquant les builds
- 20 mai 02:55 UTC : le dashboard redevient accessible
- 20 mai 03:59 UTC : le traitement des déploiements reprend sur tous les tiers
- 20 mai 04:00 UTC : il est confirmé que l’API, le dashboard et les endpoints OAuth fonctionnent, tandis que la restauration des workloads restants se poursuit
- 20 mai 06:14 UTC : l’incident passe en phase de surveillance
- 20 mai 07:58 UTC : l’incident est résolu
Cause et déroulement de la restauration
-
Suspension du compte Google Cloud
- Le 19 mai à 22:20 UTC, Google Cloud a placé par erreur le compte de production de Railway en état de suspension dans le cadre d’une action automatisée
- Cette mesure a affecté plusieurs comptes au sein de Google Cloud
- Comme il s’agissait d’une action à l’échelle de la plateforme, aucun contact préalable n’a été pris avec chaque client avant la restriction
- L’état de suspension a désactivé l’infrastructure liée à GCP, notamment Railway Dashboard, l’API, une partie de l’infrastructure réseau et l’infrastructure burst-compute additionnelle hébergée sur Google Cloud
-
Dépendance au control plane
- Le control plane de Railway constitue un ensemble de dépendances critiques : il sert le dashboard, traite les builds et déploiements, et alimente les tables de routage utilisées par l’edge
- Tous les workloads sur Google Cloud ont été immédiatement affectés
- Le proxy edge de Railway maintient un cache des tables de routage du control plane réseau hébergé dans Google Cloud
- Tant que ce cache restait valide, les workloads sur Railway Metal et AWS continuaient à traiter le trafic
- Une fois le cache expiré, l’edge n’a plus pu résoudre les routes des instances actives, et les workloads de toutes les régions, y compris sur Metal et AWS, ont commencé à renvoyer des erreurs 404
- Les workloads eux-mêmes restaient en ligne, mais l’impact de la panne réseau s’est propagé aux régions hors de Google Cloud
-
Limites de la conception haute disponibilité
- L’infrastructure Railway est conçue avec un objectif de haute disponibilité, avec des bases de données réparties sur plusieurs zones de disponibilité et un réseau reposant sur des connexions redondantes entre AWS, GCP et Railway Metal
- Toutefois, le rétablissement de l’accès au compte n’a pas entraîné la restauration automatique des services individuels
- Les disques persistants, instances de calcul et le réseau ont chacun nécessité une restauration distincte, ce qui a prolongé la panne de plusieurs heures
- Les disques sont revenus à l’état ready à 23:54 UTC, mais le réseau central et le routage edge n’ont pas été totalement rétablis avant le 20 mai vers 01:30 UTC
- Railway attend encore une confirmation indiquant si ce délai et les erreurs associées provenaient du côté de Google
-
Restauration progressive et effets secondaires
- Une fois le réseau rétabli, la validation des services cœur de Railway et des workloads finaux s’est faite par couches
- Les déploiements ont été suspendus temporairement afin d’éviter une surcharge du système de build, puis repris progressivement
- En parallèle de la restauration des systèmes critiques, GitHub a limité le débit des intégrations OAuth et webhook de Railway
- En raison du volume et du caractère burst de l’ensemble des requêtes de retry, les connexions utilisateurs et les builds ont été temporairement bloqués
- Vers 04:00 UTC le 20 mai, il a été confirmé que l’API, le dashboard et les endpoints OAuth fonctionnaient, tandis que la restauration des workloads restants se poursuivait
Mesures préventives
-
Conception de résilience existante
- Le control plane réseau de Railway est conçu selon une architecture multi-AZ, multi-zone, capable de continuer à fonctionner sans impact utilisateur même en cas de perte de plusieurs machines et composants
- Cette conception a été testée en staging et sur du trafic réel avant son lancement il y a quelques mois
- Après des incidents précédents, Railway a investi dans la résilience, ce qui lui a notamment permis de restaurer de façon stable les installations GitHub des utilisateurs sans limitation de débit secondaire
-
Suppression de la dépendance unique
- Le réseau Railway est un mesh ring composé d’interconnexions fibre haute disponibilité entre Metal <> GCP <> AWS
- Mais au sein même de cet anneau subsistait une forte dépendance : la découvrabilité des workloads restait liée à l’API du control plane réseau exécutée sur des machines Google Cloud
- Le mesh a continué à fonctionner pendant environ une heure, mais a fini par échouer à l’expiration du cache de routes, faute de pouvoir réalimenter les tables de routage
- Railway est en train de supprimer immédiatement cette dépendance afin d’en faire un véritable mesh
- L’objectif est qu’un chemin reste toujours disponible entre les clouds, quelle que soit l’interconnexion qui tombe
-
Améliorations des bases de données et du basculement
- Railway prévoit d’étendre ses shards de bases de données haute disponibilité à AWS et Metal
- À terme, même si toutes les instances d’un cloud donné disparaissent instantanément, le quorum des bases de données devra permettre au service de continuer à fonctionner et de déclencher immédiatement le basculement des workloads qui ne tournent plus
-
Refonte du data plane et du control plane
- Un plan est en cours pour retirer les services Google Cloud du hot path du data plane et ne les conserver qu’en rôle secondaire ou de basculement
- Cela s’accompagne d’un travail sur une nouvelle architecture pour le data plane, qui assure la connectivité des hôtes, et pour le control plane, qui alimente le dashboard via lequel les utilisateurs accèdent à Railway et l’administrent
- Cette mise à niveau vise à garantir que les services critiques, en particulier les composants exposés aux utilisateurs, ne dépendent d’aucun fournisseur ou plateforme unique
Responsabilité et conclusion
- La responsabilité du choix des fournisseurs incombe à Railway, et ce choix engage donc en dernier ressort Railway
- Pour les clients, peu importe que l’échec vienne de Google ou de Railway : ils jugent le produit lui-même, et le temps de disponibilité de Railway relève de la responsabilité de Railway
1 commentaires
Réactions sur Hacker News
Le point intéressant, et toujours non expliqué, est pourquoi Google a signalé le compte
On peut mettre tous les horodatages observés qu’on veut dans le post-mortem, la cause profonde n’a pas été traitée
La partie de l’histoire qui « n’a pas de sens » cache probablement une vraie explication que personne ne veut encore rendre publique
Google a coupé le compte sans préavis, alors qu’on dépensait environ 10 000 dollars par mois à l’époque
Même notre compte de support premium a été verrouillé, donc on ne pouvait même pas signaler au support qu’on était bloqués
Environ 8 heures plus tard, un ingénieur support Google choisi au hasard nous a dit que c’était parce qu’on minait du bitcoin, ce qui était totalement absurde
On avait les graphes d’utilisation CPU et les logs sur toute la période, sans aucun pic
Au bout d’environ 12 heures, ils ont réactivé le compte en disant qu’il s’agissait d’une « erreur de configuration de la détection d’abus », et nous ont donné l’équivalent d’une centaine de dollars en crédits
On peut reprocher beaucoup de choses à AWS, mais AWS n’aurait pas fait ça à un client sans qu’un interlocuteur le contacte d’abord
Depuis, je ne fais plus confiance à GCP
Les systèmes automatisés font des erreurs, mais le plus gros problème est leur opacité totale
Il est tout à fait possible que même Google ne sache pas précisément comment ce système fonctionne
Si cela veut dire que Railway devrait consacrer son énergie à ça au lieu de quitter GCP, je ne vois pas pourquoi, à moins qu’ils envisagent de poursuivre GCP pour récupérer les dégâts sur la marque et la fidélisation long terme
À partir du moment où GCP a tout coupé sans le moindre avertissement, c’était terminé, et il n’y a même plus besoin d’en demander davantage
Railway semble avoir eu une mauvaise image dans la presse tech ce mois-ci
Dans les deux cas, la réputation a été abîmée par des procédures automatisées de l’autre côté
Je comptais à l’origine parler à mon contact chez Google du problème qui a tué Gemini CLI, mais cette affaire est bien plus inquiétante
Ce sont eux, et eux seuls, qui ont mis des identifiants de compte admin dans l’IA
Et ils n’ont même pas pris leurs responsabilités personnelles, ce qui a clairement nui à leur réputation
Cette fois au moins, ils assument une part de responsabilité, donc il faut leur reconnaître ce progrès
En outre, les problèmes de fiabilité de GCP et le support client de Google sont réellement graves
Édit : je viens d’apprendre plus bas que mes deux premiers paragraphes étaient mal attribués et qu’il s’agissait d’un client de Railway, pas de Railway. Désolé, Railway !
Notre entreprise utilisait autrefois un hébergeur qui ajoutait quelques garanties supplémentaires au-dessus d’AWS
Aujourd’hui, AWS fournit directement les fonctionnalités dont nous avons besoin, donc nous avons terminé la migration vers AWS standard
Malheureusement, à cause de cela, nous avons dû faire une migration d’urgence vers Azure hier
Heureusement, nous n’avions pas notre base de données chez Railway, donc nous avons pu rétablir le service en quelques heures
La simplicité qu’offrait Railway était vraiment appréciable, mais il y a eu trop d’incidents et de limites pour continuer à faire tourner une application B2B d’entreprise sur cette infrastructure
Triste journée :(
Je connais mal le service : c’était pour une fonctionnalité particulière, ou essentiellement comme machine virtuelle ?
Si c’était pour une fonctionnalité spécifique, je serais aussi curieux de savoir à quel point la migration de sortie a été difficile
Pour de petits outils SaaS ou des produits internes, si l’équipe ne veut pas gérer directement AWS ou un autre fournisseur IaaS, quelle serait une bonne alternative ?
Même avec quelque chose comme AWS, si vous n’avez pas de redondance sur plusieurs zones de disponibilité, vous aurez parfois de l’indisponibilité
Et même avec de la redondance multi-zone, AWS n’est pas une structure totalement isolée, donc certains services peuvent quand même tomber et provoquer une panne
Il faut donc accepter les interruptions et utiliser les outils qui vous conviennent le mieux, sauf dans des cas exceptionnellement mauvais au niveau de GitHub
Si vous ne pouvez tolérer absolument aucune interruption, il faut des millions de dollars et plusieurs mois de travail pour atteindre un niveau de confiance permettant d’espérer zéro downtime
Avec Chaos Monkey de Netflix et l’infrastructure qui va avec, on devrait être couvert
Il faut au minimum deux fournisseurs pleinement opérationnels
On peut aller très loin sans tarification à l’usage
Les grands fournisseurs cloud proposent des services seulement un peu plus complexes que ce que fait Railway, avec la possibilité d’évoluer vers des fonctionnalités plus avancées à mesure que les besoins grandissent
Sans avoir à ajouter un tiers qui contrôle les fonctionnalités, la sécurité et la disponibilité
Par exemple, selon cette chronologie, GCP a répondu en 7 minutes
Si vous utilisiez Cloud Run, cela aurait réduit le downtime de plus de 7 heures, et si le déclencheur inconnu était lié à l’activité d’un autre client ou à un comportement étrange de Railway, vous n’auriez peut-être même pas subi de panne du tout
Il y a aussi la complexité
Une bonne partie de l’infrastructure complexe que Railway dit avoir dû corriger n’aurait pas été nécessaire si vous n’utilisiez que votre propre compte
Ce code fait certainement quelque chose d’utile, mais il comporte beaucoup de pièces mobiles nécessaires à un hébergeur, et pas à un utilisateur classique
Cette panne a fait tomber tout le monde en même temps, alors qu’un utilisateur individuel d’AWS ou de bare metal n’aurait pas été touché au départ
Il n’existe pas de solution universelle, mais les développeurs ont tendance à fortement sous-estimer les coûts directs et les coûts moins visibles liés au fait de travailler dans l’environnement d’autrui, par rapport au temps gagné en supprimant quelques étapes de déploiement
« 19 mai à 22:10 UTC - la supervision automatique a détecté l’échec des checks d’état API, a alerté l’astreinte et les équipes ont commencé à enquêter »
« 19 mai à 22:20 UTC - Google Cloud a placé à tort le compte de production de Railway en état suspendu dans le cadre d’une action automatisée »
Si les horodatages sont exacts, qu’est-ce qui a causé les erreurs 10 minutes avant la suspension du compte ?
L’explication la plus simple est que l’un des deux horodatages est faux, ce qui en soi n’est pas dramatique
Mais si on n’est pas sûr des horodatages, c’est quand même assez étrange de les inclure dans un rapport comme s’ils étaient établis, alors qu’ils se contredisent clairement
La section chronologique où figure 22:10 est cohérente en elle-même, et comprend aussi ceci
« 19 mai à 22:19 UTC - cause profonde identifiée : Google Cloud Platform a suspendu le compte de production de Railway »
On ne peut pas identifier la cause profonde avant qu’elle ne se produise
Par exemple, un employé Google a pu modifier un réglage par erreur, créant un signal faisant croire qu’une suspension était nécessaire, comme dans des incidents précédents, puis il a fallu 10 minutes pour que cela aboutisse à la procédure de suspension
Ou alors un client de Railway a fait quelque chose de frauduleux ou ressemblant à de la fraude, et le système Google a commencé par restreindre l’accès avant de décider pendant 10 minutes s’il fallait aller jusqu’à la suspension
S’il y avait une validation humaine dans le processus, c’est encore plus plausible
Il est juste évident que cette personne n’a pas suffisamment creusé pour voir qu’il ne fallait pas faire ça
Cela devrait servir d’avertissement à toute personne exploitant GCP
On dirait que GCP suspend des comptes à tout-va sans même réfléchir à ce qu’ils font
On dirait qu’ils confient les décisions de production à Gemini 3.1 Pro
TK a des antécédents de destruction complète de la culture d’organisation chez OCI, et d’après ce que j’ai entendu, il aurait fait quelque chose de similaire chez GCP
GCP et Google sont des organisations qui fonctionnent de manière totalement différente
Il ne faut pas s’attendre à la qualité Google juste à cause du nom
C’est un peu comme Nokia : une vieille marque désormais collée à des produits sous licence bon marché. C’est une exagération, mais pas très loin de la vérité
En plus de ça, ils sont aussi connus pour arrêter des services au hasard en laissant environ six mois pour migrer
Ils ont beaucoup d’ingénieurs sans vraie charge, alors ils peuvent les affecter à sortir les utilisateurs internes de ces services, mais la plupart des clients ne le peuvent pas
Il existait un excellent billet écrit par un ancien employé de GCP, mais je ne le retrouve plus
Si vous prenez votre activité au sérieux, il faut éviter GCP comme la peste
Édit : ironiquement, Gemini m’a retrouvé ce billet. Il vaut la lecture : https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
Le nom est suffisamment connu pour monter en haut de la page d’accueil de HN, donc à une étape ou une autre, on peut imaginer trouver quelqu’un chez Google pour intervenir
Si cela m’était arrivé sur un petit produit personnel, je n’aurais eu absolument aucun recours
C’est d’autant plus regrettable que la qualité réelle des produits est plutôt bonne
Ils auraient facilement pu devenir le numéro 2 du marché, parce que Azure est très instable et sa documentation médiocre
Si GCP est troisième, c’est en grande partie de leur propre fait
Mon avis, totalement spéculatif, est qu’il est arrivé pour jouer l’adulte discipliné et corriger l’approche trop laxiste de Google vis-à-vis de l’entreprise
Comme le montre cet incident, il reste encore du chemin, mais c’était peut-être nécessaire pour devenir une organisation enterprise « sérieuse »
Il est possible en revanche qu’il ait créé dans le processus une culture en conflit avec le reste de Google
Cela dit, OCI avait-elle déjà une culture assez destructrice pour qu’il la détruise ? En revanche, il semble plausible que TK ait importé cette culture chez Google
Il ne faut jamais les utiliser pour quelque chose d’important
Ce n’est pas la première fois que Google Cloud casse gravement un compte client : https://cloud.google.com/blog/products/infrastructure/detail...
« Railway assume la responsabilité de son choix de fournisseur, et au final ce choix nous appartient. Nos clients se moquent de savoir si la panne vient de Google ou de Railway. Ce qu’ils voient, c’est notre produit. Votre disponibilité est de notre responsabilité, et nous continuerons à l’assurer »
Il faut saluer le fait qu’ils le reconnaissent, et pas seulement en mode RP
Faire confiance à GCP était un échec d’architecture côté Railway, et ils montrent qu’ils essaient de le corriger
Auraient-ils dû le prévoir ? Oui. Mais mieux vaut le faire tard que ne pas le faire du tout
« Enfin, nous prévoyons de retirer les services Google Cloud du hot path du data plane et de ne les conserver que pour des usages secondaires / de bascule »
C’est assez clair
On ne peut plus faire confiance à Google comme fournisseur de services B2B
Une entreprise s’est retrouvée avec son application OAuth Meta totalement inutilisable simplement parce que le compte Facebook personnel d’un de ses développeurs avait été bloqué par Meta sans raison
Ils ont tenté plusieurs escalades sans parvenir à joindre qui que ce soit
Meta est pire, parce que le compte doit être « personnel »
Même si vous avez Business Manager, tous les utilisateurs ajoutés y restent liés à des comptes Meta/Facebook personnels
C’est absurde
Google a prouvé à maintes reprises qu’on ne peut pas lui faire confiance comme prestataire de services précisément à cause de ce type de problème
C’est pour ça qu’il faudrait les découper en des dizaines de morceaux
Ce n’est souvent qu’après la colère publique des utilisateurs et la diffusion de l’affaire qu’ils reviennent en arrière, trop tard
Google s’est toujours comporté comme s’il n’avait aucune obligation envers ses clients payants
À mon avis, c’est la partie la plus importante
Un fournisseur cloud ne suspend pas un compte entier sans aucune raison