Exit code 137 on Railway: why your service was killed, and how to see it coming
On Railway, exit code 137 almost always means the service went over its memory limit and was killed. The deployment shows as crashed. The logs end with Killed or Command failed with exit code 137, and Railway may flag that the deploy ran out of memory. For the general picture, see exit code 137 and OOM killed.
Why the graph looked fine
Railway’s Metrics tab samples memory over time, so a spike that lasts a few seconds can come and go between two points. Users on Railway Station often see 200 MB on the graph next to a 137, when the real peak was far higher. A crash with a calm graph points to a short spike: a batch job, a large upload, a build step or a burst of requests.
What sets the limit
Your plan sets the most memory each replica can use. Under the service’s Settings, Deploy, Replica Limits you can set a lower cap per replica, and each replica runs its own copy of the app.
How to fix it
- Find the peak. Set the Metrics tab to the hours before the crash, and look for climbs that never come back down.
- Cap the runtime. For Node, set
NODE_OPTIONS=--max-old-space-size=<MB>to about 75 percent of the service’s memory, so the heap stays inside it. - Cut workers. Lower
WEB_CONCURRENCYor the Gunicorn worker count. Each worker holds its own copy of the app. - Move heavy work out. Run batch jobs and imports in a separate worker service, so a spike there cannot take the web service down.
- Raise the limit, or upgrade the plan if the service has hit the plan’s ceiling.
What Railway warns you about
Railway’s monitors can alert on memory, but they need the Pro plan and are set up per environment. On Free, Trial and Hobby, nothing warns you before the kill. Project webhooks report the crashed deployment after it happens, one project at a time.