Railway had two separate incidents on 30 September 2026: a domain routing fault that returned 404 errors for roughly 5 minutes, and a dashboard and authentication slowdown lasting 31 minutes. Both were Railway's own infrastructure problems, logged and closed by the vendor the same day.
Started
07:48 UTC
Duration
Lasted 35m
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?
The first incident started at 07:48 UTC and was filed as a post facto report, meaning Railway only posted about it after the fault had already been mitigated. According to that single update, domains hosted on Railway returned 404 errors for approximately 5 minutes, though the incident's recorded duration on Railway's status page runs to 35 minutes. Railway said it was investigating the root cause but has not published a follow-up explaining what caused the routing fault. The second incident began at 15:06 UTC, when Railway reported the dashboard loading slower than usual alongside auth issues that disconnected some users. Fifteen minutes later, at 15:21 UTC, Railway posted that it was seeing recovery and continued to monitor, and the incident closed out at 31 minutes total. No components are broken out individually in Railway's own listing for either incident, and no user reports were filed in the window on either event. Across both incidents there are three updates total, which is a thin record for two separate faults affecting routing and authentication respectively. Railway's 90 day history shows 23 incidents with a median duration of 1 hour 2 minutes, so both of today's incidents resolved faster than Railway's own recent median. Over all time Railway has logged 544 incidents, averaging about 10 a month, which puts two incidents in one day within its usual pattern rather than outside it.
Learning
Railway's own status updates describe a routing fault that briefly turned working domains into 404 pages, and a separate dashboard and auth slowdown, both resolved within the hour. These are platform level failures sitting in Railway's own infrastructure, not in anything you configured or deployed, so your own application health checks would likely have stayed quiet through both. A 404 on your domain caused by the host's routing layer looks identical from inside your app to a 404 you caused yourself, which is exactly why relying only on your own endpoint checks leaves a blind spot. UptimeRobot's own 30 day data for Railway shows 4 incidents, all resolved, with a median duration of 1h 12m, a separate measurement from Railway's self-reported figures but consistent with a provider that has repeated short faults rather than one-off problems. When your dashboard loads slowly or your users get logged out without you touching anything, the fault may be sitting upstream at the host, not in your own code. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
