Railway status

How we check Railway

We watch railway.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

Deployed services answer on their own generated domains behind whatever routing each project configures, so no shared endpoint represents Railway's customers. We watch Railway's own host, which is a real signal about their infrastructure and explicitly not a measurement of your individual deployment. Railway's status page serves a page for every path, so this page links no RSS feed rather than link one that would silently return HTML.

What is Railway?

Railway is a deployment platform that takes a repository and runs it, handling the build, the container, the networking, and the databases around it without asking anyone to configure infrastructure first. The appeal is the shortest possible distance between code and something running on the internet, which makes it popular for side projects, prototypes, and a growing number of small production services.

The failure modes follow directly from that design. Because Railway builds and runs your code, an enormous share of what looks like a platform problem is your application failing in a way the platform is faithfully reporting. A container that exits immediately after starting, a health check aimed at a path that returns 404, a build that exceeded its memory allowance while installing dependencies, or a start command that works locally because of a shell alias nobody remembers all present as a deploy that will not come up. The logs for that specific deploy are the fastest way through, and they are more informative than any status page could be.

Restarts deserve their own note because they are so often misread. When a service exceeds its memory allocation or fails its health check, the platform restarts it, which is the correct behaviour and also indistinguishable from instability if you are only watching from outside. A process with a slow memory leak produces a service that works for a while, restarts, works again, and restarts, on a rhythm that looks like the platform having a bad day. The service metrics show the sawtooth clearly.

Environment variables are the third common trap, and they are specific enough to Railway's model to be worth calling out. Services reference each other through variables that the platform injects at deploy time, so renaming a database service, moving one between projects, or changing an environment can break a reference that was working, without anything having failed. The application starts, cannot reach its database, and reports a connection error that reads like an outage.

For the platform itself, the useful distinction is the same as anywhere else. Building and deploying is one system; running your already-deployed services is another. A degraded build pipeline means you cannot ship, while everything already running keeps serving traffic, and reaching for a redeploy during that window is the one action guaranteed not to help.

Frequently asked questions

Is Railway down right now?

Check the board above; it reflects our own probes against Railway from all five of our regions, refreshed every couple of minutes and confirmed across two regions before this page would say down.

My Railway deployment is failing but the platform looks fine. What should I check?

Check the build and deploy logs for that service first, since most failures are project-level. A build that ran out of memory, a start command that exits immediately, a missing environment variable in the production environment, or a health check pointing at a path the application does not serve will all fail while Railway itself is healthy.

Why did my service restart on its own?

Usually because it exceeded a resource limit or failed a health check, and Railway restarted it as designed. A process gradually leaking memory will be killed and restarted repeatedly, which looks like platform instability from the outside and is an application problem visible in the service's own metrics and logs.

Do database add-ons go down with the rest of the platform?

Not necessarily. Databases provisioned on Railway run as their own services and can be healthy while a deploy pipeline is degraded, or the reverse. If your application cannot reach its database, check whether the database service itself is running and whether the connection variable it references still resolves, since environment variables are re-injected on deploy and a renamed service breaks the reference.

How is this page different from Railway's own status page?

Theirs reports what Railway's team has observed and published. This page reports what our probes measured from outside their infrastructure, on a fixed schedule, whether or not an update has been posted yet. Ours is the earlier and coarser signal.