Search "is Railway down" and you will land, within a click or two, on status.railway.com. Read the small print at the bottom of that page and you get something most status pages leave unsaid, stated in Railway's own words:
"This status page reports incidents with significant, widespread user impact. Smaller or isolated issues won't show up here. If you are experiencing an issue, please report it at station.railway.com."
The statement is worth reading twice, because Railway is telling you exactly what the page is for and, more usefully, what it is not for. If your one deploy is failing, your one region is having trouble, or your one service cannot reach the database, the status page is not where that shows up, by design.
What does Railway's status page cover?
Railway's status page covers the platform itself when something big is happening. It tracks:
- The dashboard, the public API, Dev Studio and the support platform.
- Domain registration and provisioning.
- Every supported login method (GitHub, Google, email, OAuth), and billing.
- Regional infrastructure (builds, deployments, compute, storage and networking) across its US East, US West, EU West and Southeast Asia regions.
When Railway itself is broadly impaired, that granularity is genuinely useful. You can tell whether the problem is the build pipeline or networking in a specific region, rather than one undifferentiated red banner.
What does "significant, widespread" leave out?
Most of what you might personally hit falls on the excluded side of the page's own scoping statement. Three cases stand out:
- A single deploy that fails or hangs. The cause may be your own build config or a transient problem on Railway's build fleet for that one job. Either way the incident is not widespread, so it is not on the page.
- A regional degradation below Railway's significance threshold. Elevated latency or intermittent errors in one region, short of a full regional incident, is the kind of partial problem a status page's human-decision publishing process is slowest to catch. The general pattern is covered in why "is it down" sites disagree.
- Your own service being unreachable while the platform is fine. A crashed process, a bad environment variable after a deploy, or a database connection your app cannot establish are not Railway's problem to report, because they are not Railway's problem at all.
The table below maps each case to where it shows up and where to look first.
| What broke | On Railway's status page? | Where to look first |
|---|---|---|
| A platform-wide incident | Yes | The status page, then a probe of Railway's API |
| One region degraded below the significance threshold | Not unless it crosses the threshold | A probe of Railway's API from several regions |
| One deploy failed or hung | No | That service's deploy logs |
| Your service crashed or lost its database connection | No | Deploy logs, then an HTTP check on your public URL |
Railway names station.railway.com as the right channel for an isolated issue of your own. That is a deliberate design choice, not an oversight. A green status page therefore tells you less than it feels like it tells you.
How do you tell whether it is Railway or your own project?
Run a direct probe, because only a signal from outside both Railway's dashboards and your own deploy logs separates an unpublished platform issue from a broken project.
The RealUptime Outages page for Railway shows readings of three targets:
- Railway's public marketing site.
- Its own status page.
backboard.railway.com/graphql/v2, the GraphQL API the dashboard itself runs on.
The readings come from up to ten regions, with no dependency on any one customer's project or region, and each region's reading is published separately. A reading is one measurement from one place at one time. Our probes can be wrong too (retractions are listed at /outages/corrections), so a reading is a clue, not a verdict.
If the API endpoint answers while your one service is down, that may point at your deploy, though an answering endpoint does not show the platform is healthy. You also save the time you would have spent waiting on a status page update that Railway's own scoping rules say may never come for an issue this size. If the endpoint is failing from several regions, you have a timestamped reading to attach to a station.railway.com report, rather than "it's broken, trust me."
What should you check first when a Railway app stops responding?
Check your own deploy logs first, then the status page, then a probe. Working through these four steps in order gets you to an answer faster than repeatedly refreshing the status page:
- Check your own deploy logs first. Railway's deployments view shows build and deploy logs per service. A crash loop, a failed migration, or an out-of-memory kill shows up there immediately, and is the single most common cause of "my app is down" when Railway itself is fine.
- Check the status page, but read it as Railway describes it. Green means no significant, widespread incident has been published. It does not mean your specific service is unaffected by something smaller. Check the regional row against your own service's deployed region, the same distinction covered for Supabase in is Supabase down, or is it your project?. A platform this size runs multiple regions, and an incident in one does not always cross the threshold to appear as a top-line incident.
- Check a probe of Railway's own API, not your project and not the status page. If Railway's core API is answering from outside its own systems, that may point away from a platform incident. An answering endpoint does not show the platform is healthy, but you can stop waiting on a status update that may never come and start looking at your own deploy.
- Check whether the problem is isolated to one environment. Railway supports multiple environments (production, staging, PR previews) per project. An issue in a preview environment's build pipeline says nothing about production, and conflating the two wastes time during an incident.
Why is the gap wider on a platform than on a single server?
A platform-as-a-service is where the gap between "the platform is healthy" and "my thing is healthy" is widest. Railway's scoping statement is not unique to it. Most status pages built on the same incident-management pattern, where a human decides what counts as significant enough to publish, draw a similar line, even when they do not say so as plainly.
On a single server you control, you have direct SSH access and your own logs the moment something breaks. On a managed platform, your only visibility into the platform's internals is what it chooses to publish. Railway is telling you upfront that publication has a bar your specific problem will often not clear.
None of this is a criticism of Railway in particular. Publishing every isolated incident would make the status page useless for its actual purpose: telling people during a genuine widespread outage that yes, it is Railway and not them. It does mean the status page was never going to be your primary source of truth for your own app's health. Treating it as one costs you time during exactly the moments that time matters most.
How do you monitor the app you actually deployed?
Watch the endpoint your users hit, not the infrastructure underneath it. Whether the specific app you deployed on Railway is reachable right now is a separate, more important question than whether Railway is healthy.
A crashed process, a migration that broke on deploy, or an environment variable that did not carry over from a previous environment all take your app down while Railway's infrastructure reports nothing wrong. From Railway's point of view, your container exited the way you told it to exit. Railway's own healthchecks are only called at the start of a deployment, so they do not watch the app once it is live.
An HTTP check on RealUptime Monitor against your Railway-hosted app's real public URL, run from multiple regions, catches the case a healthy Railway status page cannot: your app, specifically, not answering. For anything on a schedule against a Railway-hosted worker or job, a heartbeat monitor alerts on the job going silent. That is the failure mode a platform-level check will never see either.