6 hours ago
We are on an active Hobby plan with the latest invoice paid and usage below the included allowance. Our production API's existing version remains reachable, but newly built versions do not stay deployed.
Observed today, 31 October:
- The image builds, the API starts, and the health check succeeds.
- The new version serves successful public requests for several minutes.
- The release detail temporarily says Active / Deployment successful, while service activity still says deploying.
- After about eight minutes it becomes Failed and traffic returns to the older version.
- A direct Redeploy from Railway reproduced the result. The final timeline showed Build 00:22, Deploy 07:52, Network 00:01, Post-deploy Not started.
- The owner has not stopped any deployments. The workspace audit log shows the expected creation/redeploy actions, with no later manual stop/removal action during this retry.
- Railway's automated diagnosis says the deployment passed its health check, then was stopped from outside the application. It does not identify the stop source.
- No application [ERROR] logs were returned for the direct retry during the inspected window.
Configuration: one EU West replica, serverless off, /health with a 120-second healthcheck timeout, numeric overlapSeconds 0 and drainingSeconds 15.
These current threads describe closely matching symptoms:
https://station.railway.com/questions/deployments-fail-after-8-min-in-configu-77b55fad
https://station.railway.com/questions/services-down-9ad9825d
Please inspect the affected service linked to this thread and identify the exact failed rollout step, the source of the stop, and whether deployment promotion or CONFIGURE_NETWORK is timing out. Can Railway clear the affected routing/promotion state without replacing the working production service? Please escalate to a human engineer if the automated diagnosis cannot establish the cause.
We have paused further retries and unrelated application/configuration changes. Private deployment IDs, exact times and commit details can be provided through a staff-only channel if needed. No credentials or customer data are included here.
5 Replies
Status changed to Awaiting Railway Response Railway • about 6 hours ago
6 hours ago
Update, 31 October: one further direct Redeploy of the same tested commit and configuration reproduced the failure. The new API started and served successful requests, then Railway marked the release Failed after about eight minutes and restored traffic to the older build. The older build remains healthy. No further code, plan, region or routing changes were made for this retry. Please inspect the internal deployment-promotion/network step and the event that stops the new instance; further blind retries are not resolving it.
3 hours ago
We went through today's failed attempts on this service, including your latest retry at 12:36 UTC. Eight of them ended the same way, with traffic staying on the previous version.
The attempt at 12:00 UTC failed for a separate reason that you can fix. The service config it used had overlapSeconds and drainingSeconds set as text, and both need to be plain numbers.
Your working production version is unaffected, and replacing the service is not needed.
Status changed to Awaiting User Response Railway • about 3 hours ago
3 hours ago
Same issue here on 2026-10-31: EU West, one replica, a different project.
Healthy deployments serve traffic, then stop about 8 minutes later with no
application error, and traffic returns to the old deployment. In our deployment
data CONFIGURE_NETWORK runs about 7.5 minutes, then the container is stopped
about 19 seconds later and DRAIN_INSTANCES never runs. Five deployments were
affected. Details are in our own support thread:
Status changed to Awaiting Railway Response Railway • about 3 hours ago
3 hours ago
Thanks for adding your details. We can only look at the project linked to this thread here, so your deployments will be reviewed in your own support thread rather than this one.
To keep your project details off this public thread, please post any deployment IDs, timestamps or logs in your own thread instead.
Status changed to Awaiting User Response brody • about 1 hour ago
Status changed to Awaiting Railway Response brody • about 1 hour ago
33 minutes ago
We're looking into the repeated rollbacks after your deployments pass their healthchecks and begin serving traffic. Our automated replies haven't resolved the issue you reported, and I'm sorry for the delay in getting you an update from the team. We'll follow up here when we have more information to share.
Status changed to Awaiting User Response Railway • 33 minutes ago