9 days ago
Hi Railway team,
I get a "Deploy Crashed" email every time I deploy this service, even though the deployment ultimately comes up and runs fine — the app is live and working normally right after.
Project: amusing-wholeness
Environment: cooperative-nature
Looking at the deploy logs, the container starts, Next.js reports it's ready, and then it receives a SIGTERM almost immediately afterward:
Starting Container
trade-quote-forge@0.1.0 start
next start
▲ Next.js 16.3.3
- Local: http://localhost:8080
✓ Ready in 132ms
✓ Running next.config.ts took 22ms
npm error path /app
npm error command failed
npm error signal SIGTERM
npm error command sh -c next start
Stopping Container
A moment later the service comes back up and stays live/healthy with no further issues.
A few things I've already checked on my end:
No Healthcheck Path is set under Settings → Deploy for this service.
I only trigger one deploy at a time via railway up — no overlapping deploys or a connected GitHub auto-deploy that could be racing it.
Could you help me understand what's sending that SIGTERM right after the container reports ready, and why it's triggering a "crashed" notification even though the deployment recovers and ends up healthy? I'd like to stop getting the crash alert on every deploy if this is expected/benign behavior on your end.
Thanks,
Tim
1 Replies
9 days ago
The SIGTERM in those logs is going to your previous deployment, not the new one. Your recent deploy history shows the same pattern every time: a new deployment comes up, and less than a minute later the previous one is stopped and removed. When a new deployment goes live, we send the old one a SIGTERM. By default it gets 0 seconds to shut down gracefully before it is force-stopped (deployment teardown). The "Ready in 132ms" lines you see are from when that older container first started, and the new deployment keeps running without interruption.
The "Deploy Crashed" email most likely comes from that shutdown. When next start runs under npm start, npm reports the SIGTERM as npm error command failed, so the old container exits with an error status instead of a clean exit. That makes a normal teardown look like a crash, even though nothing is wrong with the new deployment.
To give the old deployment time to shut down cleanly, set the RAILWAY_DEPLOYMENT_DRAINING_SECONDS service variable or change the draining time in the service's settings (deployments reference). The process also needs to exit cleanly when it receives the SIGTERM rather than returning an error.
Status changed to Awaiting User Response Railway • 9 days ago
2 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 1 day ago