9 days ago
Hi,
My service "web" (project insightful-dream, environment production) keeps receiving SIGTERM and restarting roughly every 2 minutes. It boots cleanly — the deploy logs show gunicorn listening on the port and my startup completing — and then the logs show:
[INFO] Handling signal: term
…and the container restarts. This repeats on a ~2 minute cycle. During the restart the app is unreachable.
I've already ruled out the common causes on my side:
I'm on a paid plan (not a free-tier resource limit)
Serverless is OFF (so it shouldn't be scaling to zero)
No healthcheck path is configured
Railway status page shows all systems operational
The app itself boots with no errors (Flask + gunicorn, Python 3.13)
Since the SIGTERM is being issued to the container and not caused by a crash in my code, can you check what is triggering these restarts on your infrastructure side?
Details:
Project: insightful-dream
Service: web
Environment: production
Domain: web-production-b2418.up.railway.app
Recent deployment ID: 7a88554a
Thank you.
2 Replies
9 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 9 days ago
9 days ago
Hey, I highly doubt that this SIGTERM is being issued from Railway's side.
Can you share your start command?
medim
Hey, I highly doubt that this SIGTERM is being issued from Railway's side. Can you share your start command?
8 days ago
gunicorn server:app --bind 0.0.0.0:$PORT --workers 2 --threads 8 --timeout 120
(My app file is server.py, so it's server:app — not main:app.) The app boots cleanly — logs show "Listening at 0.0.0.0:8080" and "init_db complete" — then runs fine for a couple of hours, and the logs show "Handling signal: term" followed by "Stopping Container", and it restarts. Serverless is off, no healthcheck path set, paid... sorry, HOBBY plan. What would cause the SIGTERM if it's not from Railway's side?