Cloud & hosting
Is Railway down?
Live Railway status, measured independently. We probe 5 Railway endpoints from monitoring regions on every continent and record every outage we detect.
Railway is up
Our probes are reaching Railway normally from every region we check from.
Checked every minute from 6 regions on every continent.
- Uptime, 24 hoursUptime, last 24 hours
- Uptime, 7 daysUptime, last 7 days
- Uptime, 30 daysUptime, last 30 days
- Website100% uptime, 30 days6 regions, 12 to 827 msUnknownp50median response236 msp95slowest 5% of checks465 ms1000 ms500024 h ago12 h agonow
- Dashboard99.99% uptime, 30 days6 regions, 48 to 737 msUnknownp50median response252 msp95slowest 5% of checks348 ms500 ms250024 h ago12 h agonow
- Documentation100% uptime, 30 days6 regions, 73 to 803 msUnknownp50median response324 msp95slowest 5% of checks493 ms500 ms250024 h ago12 h agonow
- GraphQL API99.99% uptime, 30 days6 regions, 66 to 305 msUnknownp50median response198 msp95slowest 5% of checks388 ms500 ms250024 h ago12 h agonow
- DNS100% uptime, 30 days6 regions, 0 to 147 msUnknownp50median response61 msp95slowest 5% of checks122 ms200 ms100024 h ago12 h agonow
Daily strip:99.9% or better95–99.9%below 95%no data yet
Get notified when Railway goes down
Follow these 5 checks from your own workspace and get alerted through Slack, email, webhooks, or on-call the moment Railway goes down. They don't count against your monitor quota. Free plan, no card required.
About Railway outages
Railway is a popular platform for small teams to run services, Postgres, Redis, and cron jobs with minimal configuration. Because Railway also runs the databases, a Railway incident can take down both your app and its data layer at the same time.
We probe the Railway website, the dashboard, the documentation, and its GraphQL API. Railway's own health check runs once at deploy time, so a service that hangs later is invisible to the platform; see our monitoring guide below.
What we check
Every row is a real monitor in upti.my, running from each of our regions. A failure in some regions marks the row degraded; failures from every region mark it down and open an outage.
| Check | Target | Expects | Interval |
|---|---|---|---|
Website railway.com is unreachable. | httprailway.com | HTTP 200 | 1 min |
Dashboard The Railway dashboard is unreachable. | httprailway.com/login | HTTP 200 | 2 min |
Documentation Railway's documentation is unreachable. | httpdocs.railway.com | HTTP 200 | 5 min |
GraphQL API Railway's API is not responding at all. The dashboard, CLI, and deploy webhooks depend on it. | httpbackboard.railway.com/graphql/v2 | Any HTTP response | 2 min |
DNS railway.com is not resolving. | dnsrailway.com | A record resolves | 1 min |
For component-level detail and incident write-ups from the vendor, see Railway's official status page.
Recent Railway outages we detected
An outage is recorded when a probe fails from every monitoring region and closed when it recovers. Partial and single-region problems show as degraded above but are not listed here.
Railway is up. Is your Railway integration?
The incidents that actually hurt are usually not global outages. They are the parts of your own system that depend on Railway and fail quietly. Here is what teams that rely on Railway monitor on their side.
Monitor your Railway app properly
Railway health checks run once, at deploy time. Continuous uptime checks and heartbeats for cron services cover what the platform does not.
How to monitor a Railway appAuto-restart a hung Railway service
Railway's restart policy catches exits, not hangs. A recovery action can restart a service that is up but not answering.
Self-healing on RailwayRailway cron jobs that skip runs
Railway skips a cron run if the previous one is still executing, without an error. Heartbeats catch the skipped run.
Railway cron monitoringRailway status: frequently asked questions
An anonymous GET to a GraphQL endpoint is answered with a client error by design, and the exact code has changed over time. What we care about is that the API answers at all, so the probe fails only on timeouts, connection errors, or invalid responses.
Look at the per-region results above. If our probes fail from every region, Railway has a real outage and it will appear in the outage list. If they succeed everywhere, the problem is most likely on your side: your network, DNS resolver, a browser extension, a corporate proxy, or your own integration. If only some regions fail, Railway may have a regional incident that does not affect you.
Every probe runs at least every five minutes from each monitoring region, and most run every minute. This page refreshes its data every minute. Uptime figures are calculated from all checks across all regions.
Official status is updated by people after an incident is confirmed and often lags the first failures by many minutes; our probes react within a minute or two. In the other direction, we only see public endpoints, so an internal incident may not show on our probes. Use both.
Yes. Use "Notify me about Railway" above: your upti.my workspace follows these exact checks, free plan included, and every outage opens an incident there and routes alerts to Slack, email, webhooks, or on-call. Nothing is duplicated and it doesn't use your monitor quota. Better still, also monitor your own dependency on Railway: the API route, webhook receiver, or scheduled job that calls it, so you learn about the failure that actually affects your users.
Related
upti.my is not affiliated with Railway. Railway and related marks are the property of their respective owners and are used here only to identify the service being measured. Results reflect the reachability of public endpoints from our monitoring regions and may differ from the vendor's own reporting.