6 hours ago
Subject: Deploys stuck at "scheduling build" on builder-gfasfb — 4 consecutive failures, no build/deploy logs
Project: ctrak (project ID: 55233d5a-eba1-483e-90a8-79ef9cfb89b9)
Service: backend (service ID: bb3fd1ac-e73c-44c7-81f5-2fae1058dcb2)
Summary:
Four consecutive railway up deployments to our "backend" service have
failed, all with an identical symptom: the build log contains only a
single line — "scheduling build on Metal builder 'builder-gfasfb'" —
and never progresses to an actual build step, let alone a deploy step.
No error message, no stack trace, just silence after that line until
the deployment is marked FAILED.
Failed deployments (all same symptom, same builder ID):
-
3059a574-1c02-4ca5-a9be-072400fc6b29 — FAILED — 2026-07-13 13:14:49 -04:00
-
4c7c7dbd-c234-4422-a77f-2683ff78a4b0 — FAILED — 2026-07-13 13:15:34 -04:00
(retried immediately after #1, same result)
-
31d7965b-c960-4450-a318-a851373dff6c — FAILED — 2026-07-13 13:21:16 -04:00
(retried after a 2.5-minute wait, same result)
-
234f47f0-053b-4a09-8020-46cd9d1ca742 — FAILED — 2026-07-13 13:37:44 -04:00
(retried from the repo root instead of the backend/ subdirectory,
specifically to rule out a working-directory/Root Directory
mismatch — same result)
Notable correlation:
The same builder ID ("builder-gfasfb") also appears on an older failed
deployment from several days earlier:
3018e9d7-f7ae-4a94-a759-bdd11f2c60ee — FAILED — 2026-07-09 00:06:25 -04:00
That earlier failure was tied to a separate, since-resolved issue
(an unintended GitHub auto-deploy connection on this service, which we
have since disconnected via railway service source disconnect). The
recurrence of the exact same builder ID across unrelated deploy
attempts, days apart, suggests this specific builder instance may be
unhealthy rather than an issue on our end — our code has not changed
between the deploy that succeeded and the four that failed.
What we've already ruled out:
-
Not a code/build config issue: the same source successfully deployed
earlier today (deployment 92645a79-f9c8-4df3-954f-60763c6936f4,
SUCCESS, 2026-07-13 12:00:39 -04:00) and is still running now.
-
Not our GitHub integration: confirmed via
railway service list --jsonthat the service's source is null (cleanly disconnected).
-
Not Root Directory / working directory: confirmed in the dashboard
that Root Directory is correctly set to "backend". As an additional
test, we ran
railway up --service backendfrom the repo rootinstead of the backend/ subdirectory (deployment 234f47f0 above) to
rule out any working-directory mismatch entirely — it failed with
the identical symptom, same builder ID. The common factor across all
four failures is specifically builder-gfasfb, regardless of source
path, timing, or retry gap.
-
Not a reported platform-wide incident: checked status.railway.com,
which shows "Fully Operational," no current incidents.
-
Not a transient blip: retried four times total, including once after
a 2.5-minute wait and once from a different working directory, with
identical results each time.
1 Replies
Status changed to Awaiting Railway Response Railway • about 6 hours ago
3 hours ago
Builder-gfasfb itself is healthy, it's building other services normally. What's happening is that builds for your backend service fail a couple of seconds after scheduling, before any output is produced, which is why the log never gets past that first line. Builder assignment is sticky per service, so every retry lands on the same builder no matter where you run railway up from. We're tracking this pattern with other reports.
The fix you can do yourself: delete and recreate the backend service with the same repo and settings. A fresh service gets a fresh builder assignment. There's no volume on this service so no data is at risk, just copy your variables over first.
Railway Team
Status changed to Awaiting User Response Railway • about 3 hours ago