4 hours ago
I’m seeing a production service get removed by Railway after a successful historical redeploy, even though the application is healthy immediately beforehand.
Service: superb-adaptation
I’ve reproduced this three times. Each redeploy starts successfully, passes health/readiness checks, continues serving traffic, and shows no crash loop, fatal exception, OOM, or application-level failure. After roughly 40–45 minutes, Railway logs Stopping Container and the deployment becomes REMOVED.
Example incident:
Deployment starts successfully
Health/readiness checks pass
Application collectors continue running successfully
Memory remains normal
No OOM / crash / restart loop
Strict V3 research health remains fresh immediately before removal
Railway then stops the container externally and marks the deployment removed
The redeploys are historical redeployments of a known-good image:
sha256:94382c9c569273097f9bb0d22e331cb5c33c55cdd1d372b1e8c42905f7865ff7
The service’s canonical latestDeployment appears to still reference an older stopped/failed deployment rather than the healthy historical redeploy.
I have checked the obvious client-side causes and found:
no Railway CLI process issuing destructive commands
no cron / at jobs
no local cleanup watcher
no GitHub workflow capable of mutating Railway
no active EventEdge orchestrator capable of removing deployments
Railway auto-deploy is disabled
no application crash or OOM around the removal
I’d appreciate help understanding:
Can Railway lifecycle reconciliation remove a healthy historical deploymentRedeploy if the service’s canonical latestDeployment still points to an older failed/stopped deployment?
Is there a supported way to make a known-good historical redeploy become the stable canonical active deployment without rebuilding current repository HEAD?
Is there any Railway-side lifecycle rule that would explain a healthy deployment being removed after ~40–45 minutes?
I’ve removed internal project/environment/service/audit UUIDs from this public post. I can provide those privately to Railway staff if needed.
Thanks.
1 Replies
Status changed to Awaiting Railway Response Railway • about 4 hours ago
4 hours ago
This is the kind of problem the Railway community is well placed to help with, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.
Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.
- Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
- Keep it private and close the thread - Nothing becomes public and the thread closes.
Status changed to Awaiting User Response Railway • about 4 hours ago
3 hours ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 3 hours ago