a month ago
Project: (ID 08f1c17b-32cb-4df2-98d0-997311e255d0), production environment, US West.
Issue: Since ~21:00 UTC on Jul 8, every standard deployment on this project fails at "Deploy › Create container" (or "Pre deploy command") in under 400ms with "Failed to create deployment", before any application code runs. Builds always succeed and images push cleanly. Existing deployments keep serving throughout. ~20 failures over 17 days.
What we've ruled out, with evidence:
Service config: a brand-new service (crm-web-2, ID ff939be4-3032-4237-a7b3-93ff3b7ebb33) with fresh config failed identically on its first-ever deploy.
Pre-deploy command: removing it entirely just moved the failure to "Create container".
Plan/resources: we upgraded from Trial to Hobby today (Jul 25) — failures continued after propagation (deployment IDs 2294657f, 23d5f91e).
Reference variables: replacing ${{Postgres.DATABASE_URL}} with a literal connection string changed nothing.
The isolating result: enabling Serverless on crm-web-2 made it deploy and initialize immediately — the first successful container creation on this project since Jul 8. Same image, same variables, same region; only the scheduling path differed. This points squarely at the standard (non-serverless) container scheduler for this project/workspace in US West.
Failed deployment IDs (sample): a6b78225, 6cad8b08, 4dd20bce (Jul 8) · 3def1666, 98972374, f85d29d7, 13d7741d (Jul 9) · 2294657f, 23d5f91e, 14c71c0a (Jul 25, post-upgrade).
Note: your in-app Diagnose tool attributed this to a platform issue and advised contacting support if it persists. We're running production on serverless as a workaround, but need standard scheduling restored (our scheduler service requires it — serverless doesn't support cron/always-on).
4 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 27 days ago
23 days ago
No errors in either log - that's the strange part. Build logs complete successfully every time (image builds and pushes cleanly). Deploy logs are empty: the deployment dies at Create container in under 400ms, before any container starts, so nothing is ever written to them. The only visible failure is the deployment status itself flipping to Failed to create deployment. Consistent across all ~20 attempts (sample IDs in the OP). The same image/variables/region deploys fine the moment Serverless is enabled, which is why this looks like the standard scheduler path for this project. Happy to trigger a fresh failing deploy on a scratch service if it helps you trace it live.
23 days ago
Why This is Happening (Platform Root Causes)Ghost Constraints/Zombie Allocation Blocks: The standard cluster scheduler likely thinks your project has exhausted localized placement allocations or volume attachments tied to standard nodes in US West.Project Corrupted State on Standard Pool: A stuck lock in Railway’s control plane database for your project ID (08f1c17b-...) is rejecting the standard placement logic instantly, whereas the serverless path bypasses this specific placement database completely.Regional Node Exhaustion Grouping: Your workspace might be tied to a specific sub-cluster of standard US West nodes experiencing scheduling desynchronization.Actionable Steps to Force a Scheduler FixSince you are running production workloads that need an always-on standard scheduler for cron tasks, you can try these zero-code structural infrastructure workarounds before support manually flushes your project state:1. Trigger a Regional Workspace MigrationThe goal is to force Railway's control plane to assign your project a completely fresh scheduling context.Navigate to your Project Settings.Check if you can change the Region from US West to another zone (like US East).If successful, switch it, deploy under standard scheduling, and then switch it back to US West. This forces the control plane to teardown and re-provision the underlying workspace metadata.2. Duplicate the Workspace (Not Just the Service)You proved duplicating the service (crm-web-2) failed because it inherited the broken project-level orchestration state.Create a completely new, separate Railway Project within your Hobby account.Link it to the same GitHub repository and production environment variables.Deploy using the Standard Scheduler in the new project. If it succeeds, the issue is strictly a corrupted metadata state on your old project ID, and you can safely migrate traffic to the new project.3. Implement an Interim "Always-On" Keep-AliveIf you must remain on the Serverless scheduler temporarily while waiting for the Engineering team to resolve the ticket, your cron/background processes will sleep.The Workaround: Use an external uptime monitoring tool (like UptimeRobot or Better Stack) to ping your Serverless application URL every 30 seconds to 1 minute. This keeps the serverless container permanently warm and awake to process background worker cycles until the standard scheduler is fixed.
23 days ago
In that case, could you please share a screenshot of the Details window? It should provide more information about the failure and help me better understand what's causing the issue.