Seeing the exact same failure mode on a separate, unrelated project — this looks platform-wide, not project-specific.

Project: socratic-url-gateway (ID f72972ad-af8b-4644-8f23-912656e0f3d6), service socratic-url-gateway.

Every deployment attempt fails at build scheduling with zero actual build output — never reaches cloning, npm install, or any real build step. The only build log line is always: scheduling build on Metal builder <builder-id>, then the deployment is marked FAILED seconds later.

Confirmed across 7 separate attempts, ruling out anything project-specific: 2 different services (deleted and recreated once, same result), 2 different regions (us-west2 default, and us-east4), and 3 different builder instances (builder-xqerub, builder-noxrei, builder-cpzdgy).

Deployment IDs: 0ea8b400-8e1c-42c2-b17e-564242c33a64, b1d94a69-0208-4c17-99aa-48e53bc19b61, f8072d67-09ab-4fa4-a5f1-7b67f08b7f12, 94b2983b-a43a-40d0-a10e-5eabd217de13, 1559ee08-77d9-40b6-80b3-a3e83aa6c4a7, 53bd77df-2812-4084-b669-746d433dc3ba.

Both a GitHub-triggered build and a direct CLI (railway up) build hit the identical failure, so it's not a GitHub integration issue. Checked the dashboard thoroughly (Project Settings and Workspace Settings) — no self-service toggle to work around it.

Is there a way to disable/reset the Metal builder for a project or workspace, or otherwise unblock scheduling?

Is this issue occurs on fresh commit or only on redeploys?

Both — happens on fresh commits and redeploys alike.

Specifically:

• The very first deploy ever triggered on the original service (auto-deploy on GitHub link, commit bf1eaa3, a brand-new first-ever build) — failed.
• A push of a genuinely new commit (f233e47) triggering a fresh GitHub-webhook build — failed.
• A direct CLI upload (railway up, not GitHub-triggered at all) — failed.
• Deleting the service entirely and recreating it fresh, so the very first deploy on the new service (a completely clean state, no prior history) — still failed, identical symptom.
• Switching regions (us-west2 → us-east4) on the fresh service, first deploy in the new region — still failed.

So it's not specific to redeploys, cached state, or a stale service — every single attempt across 7 tries, 2 services, 2 regions, and 3 different builder instances has failed identically at the scheduling step, including multiple genuinely "first ever" deploys.