Railway had two separate incidents on 5 October: GitHub-triggered builds queued up for 1h 22m starting at 14:55 UTC, then the dashboard became slow or hard to load for 39m starting at 15:37 UTC. Both problems sat on Railway's side, in the build pipeline and the dashboard backend, not in anything you configured.
Started
14:55 UTC
Duration
Lasted 1h 22m
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 two incidents within about 40 minutes of each other. The first started at 14:55 UTC and affected builds triggered by GitHub pushes, with Railway saying users could see builds queuing or taking longer than usual to start. At 15:40 UTC Railway said it had identified the issue and was working on a fix, and by 15:52 UTC it reported the build queue was draining, though it warned builds could still take longer than usual while the backlog cleared. That incident ran for 1h 22m in total. The second incident began at 15:37 UTC, while the first was still draining, and hit the Railway dashboard itself, with users possibly seeing slow load times or trouble accessing it at all. Railway reported recovery in dashboard response time at 15:57 UTC and said it would keep monitoring. That second incident lasted 39m. Railway has not published a cause for either issue, so neither root cause is on the record. No components are listed as formally affected on the status page for this day, and no user reports were filed during the window. Across both incidents there were five status updates in total, all from Railway, and no post-mortem has been published for either.
Learning
A delay in GitHub-triggered builds or a slow-loading dashboard will not usually trip an uptime check, because those checks are built to watch your own endpoints responding to the public internet, not Railway's internal build queue or its own admin interface. That's the layer that failed here: build orchestration and the dashboard backend, both pieces of Railway's infrastructure that sit behind the scenes of whatever you actually deploy. Your product's live endpoints could have stayed completely healthy throughout both incidents while your ability to ship a new build, or even to see what was happening, was stalled. Railway's own history here isn't unusual either, with 28 incidents in the last 90 days and a median duration of 1 hour 12 minutes, so build and dashboard hiccups of this shape recur fairly often. If you only watch the parts of your product your users touch, episodes like this stay invisible until you try to push a fix and find the queue backed up. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
