3 months ago
A platform-level issue in the container creation/swap during deployment. The new container is allocated and the image
loads, but the process is SIGKILL'd before the entrypoint (python start.py) executes. This does not happen when
railway restart restarts the process within an already-running container. The zero-log pattern with
zero-memory-pressure is consistent with reports from other Railway users (e.g.,
https://station.railway.com/questions/container-builds-successfully-but-produc-15330dcd).
Pinned Solution
3 months ago
Since cron has already been removed, another thing worth checking is whether the application is binding to Railway’s dynamic PORT.
On Railway the runtime port is assigned through the $PORT environment variable, so if uvicorn or FastAPI is binding to a hardcoded port (like 8000 or 8080) the container can start but never become reachable by the platform proxy. When that happens the health check fails and Railway terminates the container, which can result in a 502 with no visible runtime logs.
Because railway restart happens inside the already running container, timing differences sometimes allow the process to bind successfully before the health check fails, which would explain why the restart consistently fixes it.
It may help to confirm the server is started like this:
uvicorn app:app --host 0.0.0.0 --port $PORT
or inside Python:
port = int(os.environ.get("PORT", 8000))
uvicorn.run(app, host="0.0.0.0", port=port)
Also worth verifying that the container does not exit early due to a failed dependency initialization (DB connection, migrations, etc.) before the server starts
3 Replies
3 months ago
I think we should revisit this issue after the cron schedule is removed from your service, as cron schedules should not be used on continually running tasks.
https://docs.railway.com/cron-jobs#when-not-to-use-railways-cron-jobs
Status changed to Awaiting User Response Railway • 3 months ago
3 months ago
Removed the cron and still get a the 502 error that causes me to have to restart each time.
Status changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 3 months ago
3 months ago
Since cron has already been removed, another thing worth checking is whether the application is binding to Railway’s dynamic PORT.
On Railway the runtime port is assigned through the $PORT environment variable, so if uvicorn or FastAPI is binding to a hardcoded port (like 8000 or 8080) the container can start but never become reachable by the platform proxy. When that happens the health check fails and Railway terminates the container, which can result in a 502 with no visible runtime logs.
Because railway restart happens inside the already running container, timing differences sometimes allow the process to bind successfully before the health check fails, which would explain why the restart consistently fixes it.
It may help to confirm the server is started like this:
uvicorn app:app --host 0.0.0.0 --port $PORT
or inside Python:
port = int(os.environ.get("PORT", 8000))
uvicorn.run(app, host="0.0.0.0", port=port)
Also worth verifying that the container does not exit early due to a failed dependency initialization (DB connection, migrations, etc.) before the server starts
Status changed to Solved sam-a • 3 months ago