8 days ago
Deployments created by railway up --ci (project XYZ, service web, production) come up with a container that never serves. Every request — including static files like /robots.txt — hangs for exactly 15 seconds and returns "Application failed to respond". There are no deploy logs at all for those deployments.
railway service restart on the same deployment fixes it immediately: the app then logs "Ready in 96ms" and serves in under 0.3s. So the image is fine.
In railway deployment list --json, these deployments show "meta": {"buildOnly": true, "reason": "deploy"}. Redeploys triggered by a variable change show buildOnly: false. I've had to restart the service after every single deploy for the site to come back.
Is buildOnly: true expected for railway up --ci, and is that why nothing runs?
1 Replies
8 days ago
The web service in production has a cron schedule set (0 7 * * *). That turns it into a scheduled job: a new deployment gets its container created, but the start command only runs when the schedule fires, at 07:00 UTC daily. That's why the new deployments have no deploy logs and requests time out until you run a restart.
Cron is meant for short tasks that exit when they finish, not for long-running web servers. To fix it, open the web service's Settings, clear the Cron Schedule field, and deploy. If you use config as code, also remove deploy.cronSchedule from your config file or set it to null, since file values take priority over service settings.
If that daily 07:00 UTC run is a real task, put it in a separate service that runs the task and then exits. See Cron Jobs.
Status changed to Awaiting User Response Railway • 8 days ago
14 hours 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 • about 14 hours ago