a day ago
Workspace: Zeutara (Internal), workspace id 7719e606-a419-4153-8fc2-cd749dafefb1. Project 10769ba6-137a-4b25-a7c3-15d13fa93cef, environment production (c4f41134-2154-4f7f-b155-b24504fc4c4f). Service: Vantage, service id c25a6b01-cd17-4f43-ad90-bc7bbf706ef1, US East, 1 replica, custom domain vantage.zeutara.com.
Since 2026-09-26 03:34 UTC every new deployment of this service fails the same way. The deployment view shows Initialization, Build and Deploy all completed (about 5 to 6 minutes each), then Network: Not started and Post-deploy: Not started, and the deployment is marked Failed after roughly 18 minutes. The build log ends after image push (636 MB, about 20 seconds). There are no deploy logs at all. Your Diagnose feature on deployment 3c38a80e says: Infrastructure Error. This deployment failed due to a network issue on Railway's side, not something in your code or config. The build completed successfully and the container was created, but every request to it timed out with a connection dial timeout error until the container was eventually stopped.
Failed deployment ids, newest first: e2c4b33e (commit c47f95d7, 15:34 UTC), 3c38a80e-585a-41e8-bc4a-69a3ec036c1b (commit cce9241b, 15:02 UTC), 7b92893c-afb1-4a48-8712-0b9ce87e5ce0 (commit 4e0e5f32, 14:01 UTC), a0187c0a-7447-4a6b-997d-083cb4d1c5f3 (commit a4bd4b20, 04:16 UTC), 48a20ea0-b7c7-47cb-94eb-28e8cb2fd2c9 (commit 8179f9b3, 03:54 UTC), 916d319e-0b9f-457f-a187-1b529c153f9f (commit dd259c32, 03:34 UTC).
The last successful deployment, 9df6f1e1-7e56-42f7-ab4b-ecffba133de9 (2026-09-25 15:29 UTC), is still active and serving. Nothing in the service's build or deploy configuration changed between that deployment and the first failure (railway.json is identical: Nixpacks, npm run build, npm run start, healthcheck /api/health, timeout 300). DNS is a CNAME to 96a8o54z.up.railway.app and resolves correctly.
Our workspace had a past-due invoice during the first four failures; it was paid on 2026-09-26 at about 14:30 UTC and the billing page shows no unpaid invoice. Failures continued after payment.
Control test: we redeployed the last good commit (4f21c779) as deployment f5d1b321 at 15:28 UTC. It rebuilt, its container started and logged normally, and the healthcheck succeeded at 15:33:49 UTC. At 15:35:59 UTC the container received SIGTERM (Stopping Container) and the deployment was marked Failed with Network Not started. So even known-good code cannot get past the Network stage on this service since 03:34 UTC today.
Please restore this service's ability to complete the Network stage, or tell us what on our side is blocking it.
2 Replies
Status changed to Awaiting Railway Response Railway • 1 day ago
a day ago
Update with new evidence. Deployment fb7848f9-fbdd-4318-a854-c831061fbb01 (commit cafae450, 16:44 UTC) was marked Active but had no deploy logs and the domain returned 502 for about three minutes. A manual Restart of that deployment from the dashboard brought its container up at 17:01 UTC: deploy logs appeared, migrations ran, Ready in 463ms, and the domain served the new build for about four minutes. At roughly 17:05 UTC the deployment flipped to Failed (Network: Not started) and traffic fell back to the old deployment 9df6f1e1, which is still serving. So the container itself is fine and reachable; something in the Network stage stops every new deployment on this service a few minutes after it starts. Private Networking and the custom domain both show healthy in the service settings. Service id c25a6b01-cd17-4f43-ad90-bc7bbf706ef1.
4 hours ago
Your Vantage service has a cron schedule saved on it with two schedules on separate lines ("0 11 * * 1" and "0 11 * * 1,3,5"). That value can't be parsed, so it had been ignored. A change we shipped just before your first failure stopped ignoring it.
Clearing the Cron Schedule field under Vantage, Settings, Deploy and redeploying will fix it
Status changed to Awaiting User Response Railway • about 4 hours ago
Status changed to Solved echohack • about 4 hours ago