Why a Railway service keeps restarting, and how to hear about it first
A Railway service keeps restarting because its process exits and the restart policy brings it back. The default policy is On Failure with up to 10 restarts. When they run out, the deployment shows as crashed. Open the deployment’s logs and read the last lines before each restart. Memory at the limit on the Metrics tab points to an out-of-memory kill. For the general picture, see why a container keeps restarting.
Railway’s restart policy
Set it in the service’s Settings:
- On Failure restarts after a crash or a non-zero exit. This is the default, with up to 10 restarts.
- Always restarts whenever the service stops, for any reason.
- Never leaves a stopped service stopped.
Free and trial workspaces cannot use Always, and On Failure is capped at 10 restarts there. Paid plans can use any policy with any number of restarts.
Common causes on Railway
- A missing variable. A variable set in one environment but not the other, or a reference variable pointing at a service that was renamed.
- The wrong port. The app must listen on the
PORTvariable Railway sets, on0.0.0.0. - Out of memory. The logs end with
Killedand the exit code is 137. See exit code 137 on Railway. - A start command that finishes. A migration or script as the start command exits with 0, and Always starts it again.
- A database that is not ready. The app exits when the database is still starting after a redeploy. Retry the connection in the app instead of exiting.
What Railway tells you
Railway notifies you when a deployment crashes or fails, and a project webhook can post it to Slack or Discord. The restarts before that final crash send nothing, so a service that crashes and recovers ten times an hour looks healthy. CPU and RAM monitors with email need the Pro plan, and each project has its own webhook.