Railway's platform went down starting at 07:24 UTC on 21 October, taking the dashboard, API, CLI and build pipeline with it. The fault sat on Railway's side, and as of the last update shown, at 08:01 UTC the next day, deployments were still queued and recovering unevenly across plan tiers.
Started
07:24 UTC
Duration
Ongoing
Source
IsDown
Next time
Railway is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
What happened?
Railway's status page logged the first investigating notice at 07:24 UTC, and by 08:28 UTC the company said the backend was affected too. At 09:28 UTC Railway identified the issue and confirmed the dashboard, API and CLI were unavailable, with new builds paused in all regions and their own support site knocked out as well. Over the following hours the picture barely moved: 11:33 UTC brought the API partly back, but builds stayed paused through 13:40, 16:29 and 17:18 UTC updates, each repeating that the build and deployment pipeline was still down. From 17:45 UTC onward Railway shifted to a fixed cadence, posting at least every 30 minutes even when there was nothing new to say, which is itself a sign of how long this dragged on. Railway laid out a staged recovery plan at 19:15 UTC, restoring builds by workspace tier: Enterprise first, then Pro, Hobby, then Free and Trial. At 19:30 UTC they gave a target of 20:30 UTC for Enterprise builds, and at 20:19 UTC disclosed that OAuth sessions were being invalidated because of impact on adjacent cache systems, signing some users out. Then at 21:59 UTC the incident turned into something more serious: Railway published a separate security disclosure, recommending that every customer revoke all environment variables, including API keys and private registry credentials, and review service logs for unusual activity. Updates after that covered rotating storage bucket credentials, including a note at 22:45 UTC explaining that an account named "Faraz Patankar" performing bulk credential revocations in customer audit logs was expected and authorised. By 08:01 UTC the next morning, builds were reported live for Pro and Enterprise workspaces, with Hobby, Free and Trial still pending, and deployments running slower than normal. One user in France reported the ongoing build and API disruption at 14:06 UTC, echoing the status page's own wording. Railway's status page recorded 36 updates in total for this incident; this account draws on 23 of them.
Learning
This outage did not just stall builds, it reached into credential security, which changes what you should do when you see a Railway incident open. The failure sat in Railway's build pipeline, API and underlying cache and storage systems, a layer entirely outside your own application and invisible to checks aimed at your own endpoints. Watching your own service tells you whether your product is reachable, but it says nothing about whether your provider can accept a new deployment or whether your stored credentials are still private. Over the past 90 days Railway has logged 28 incidents with a median duration of 1 hour 22 minutes, and across all time the company averages roughly 10.3 incidents a month, so a single long outage like this one is out of the ordinary pattern even for a provider with frequent shorter blips. UptimeRobot's own 30 day figures for Railway show 14 incidents with 13 resolved and a median duration of 54m, a different slice of the same instability. The gap between a short typical incident and this one, which ran well past a day with a security disclosure attached, is exactly why duration and cause matter more than incident count alone. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.</learned>
