Railway 5xx errors and “Application failed to respond”
Railway 5xx errors most often start as a 502 with “Application failed to respond”, returned when its edge proxy cannot reach your app. Most of the time the app is listening on the wrong port, bound to localhost instead of 0.0.0.0, or too busy to answer. Railway charts each service’s 5xx responses and error rate, but it does not alert you when they climb. For the general picture, see 5xx errors.
Where Railway shows 5xx errors
Each service’s Metrics tab has an HTTP section: responses grouped into 2xx, 4xx and 5xx, the error rate, and p50, p90, p95 and p99 latency.
The usual causes of a Railway 502
- The port does not match. The app does not read the
PORTvariable, or the public domain’s target port is not the port the app listens on. - The app binds to localhost. It listens on
localhostor127.0.0.1instead of0.0.0.0, so the proxy cannot reach it. - The service crashed or ran out of memory and is restarting. See exit code 137 on Railway.
- The service is overloaded: CPU pinned near its limit, so requests queue until they fail. More replicas spread the load.
What Railway does not alert on
Railway’s monitors alert on CPU, memory, disk and network egress, and they need the Pro plan. There is no monitor for HTTP error rate, so a service can fail one request in five for an hour without anyone being told. Project webhooks report crashed deployments, but a service that stays up while failing requests never crashes.