6 hours ago
Two deployments in this project have been stuck in QUEUED status for over 3 hours with zero build activity and no build logs generated:
Service: superbrain-options (6de1a87d-d5c3-4d8a-a925-8c503949b95e)
Deployment ID: d91c21a4-89ee-405a-88ef-89cc7e7dafea
Triggered: 2026-08-25T23:17:12Z
Service: heartfelt-endurance (cf4b0f3e-7cff-4687-9f43-30b4171b62a5)
Deployment ID: d7a65db6-1c9e-4e6f-a07f-f24bf019d276
Triggered: 2026-08-25T23:19:46Z
Both deployments completed their build stage successfully (Docker image built and pushed — confirmed via build logs), but neither has progressed past QUEUED to actually start running. No new build or deploy logs have appeared since the image push. Status has not changed across multiple checks spanning 3+ hours.
I checked status.railway.com — it currently reports "Fully Operational" with no active incidents, and EU West (where these services are hosted) shows 100% uptime today. I have not seen a "Limited Access" banner in the dashboard.
What I've already tried:
Manually triggering redeploys via the Railway API (no change — new deployments also entered the same stuck queue)
Waiting over 3 hours with periodic status checks
Confirmed no build-slot contention from other deployments in progress
Request: Could someone check whether these two deployments are actually assigned to a build/deploy worker, or if they're stuck in the scheduler? I'd appreciate either an ETA or manual intervention to get them processing, since this is blocking a live production fix.
Additional context: In the same project, I also found an older, separate deployment on service superbrain-options (deployment 8b409162, project fabulous-nurturing) that is crash-looping with Error: DATABASE_URL must be set — this appears to be an unrelated, pre-existing issue on a possibly-stray service, not connected to the queue problem above. Flagging in case it's relevant, but the queue issue is the urgent one.
1 Replies
6 hours ago
Your workspace's 3 Hobby deploy slots are all held by dozens of earlier deployments of heartfelt-endurance, each stuck on its pre-deploy command for up to 19 hours without exiting. There are 44 deployments occupying slots and 41 queued behind them (including the two you mentioned), and each redeploy attempt that acquired a slot also hung at the same step, compounding the problem. To unblock the queue, cancel or remove those stuck heartfelt-endurance deployments from your project, then investigate why the pre-deploy command hangs instead of exiting (common causes: a migration blocked on a database lock, or a script that errors but waits for input instead of exiting non-zero).
Status changed to Awaiting User Response Railway • about 6 hours ago