Project: castan-emissao-certidoes (255d19be-cadc-4485-a47d-4637a6164712)

Environment: production (c4ea4f65-6a6f-4118-8441-7c68945acded)

Service: castan-certidoes-web (929712a9-a7d6-4871-b9a8-da1c4e6608f0)

Repo: adrianogimenes/castan-emissao-certidoes, branch main

ISSUE 1 - every deployment fails instantly at BUILD_IMAGE with no usable logs.

Across 8+ consecutive deployment attempts, spanning several commits, the build fails at the BUILD_IMAGE stage in about 2-5 seconds, with the build log containing only one line: "scheduling build on Metal builder "builder-egpkfb"". No further build output, just the generic "Failed to build an image. Please check the build logs for more details." SNAPSHOT_CODE (repo clone) completes successfully and quickly beforehand, so it is not a repo-access or clone problem.

I tried both builders to rule out a config/code issue:

• Default RAILPACK builder: failed identically.
• • Explicitly switched to the DOCKERFILE builder (dockerfilePath set to "Dockerfile", confirmed via API showing build.builder = "DOCKERFILE"): failed identically, same single log line, same ~2-5s timing.

Since the failure happens before the builder would plausibly even read a Dockerfile or Railpack plan, and happens identically under two completely different builders, this points to something failing at the build-scheduling layer itself, not our repository or build configuration.

Recent failed deployment IDs: fb3f771c-2d7b-41ff-8f5b-ad40a3c837e2, 7211d1f2-51da-4b80-8f65-6914ff27ed67, 907bb7fa-8670-4bae-ad7d-19d8f1fff93e, 0f10166a-8047-4fe7-819c-8fc982261c1e, ec0cd62a-31d6-4323-ad15-98987abf4034, 36fc0904-3a42-41be-9e43-514135880f04, 960db187-2ede-4a5c-8f5f-7ad44ded60a6, d49ac9c6-af25-44cb-bb0f-d06ee490b565

Already ruled out on our side:

• Platform status page: no active or recent incidents.
• • Project-level and workspace-level feature flags: both empty via API.
• • Plan limits (Hobby tier entitlement): well within headroom.
• • Repo structure: confirmed clean, correct root-level Next.js app, no stale nested duplicate directories.
• • Trial verification: added a payment method to rule this out too. Limited Trial only restricts runtime network egress/ports, not the BUILD_IMAGE stage, so this was not it either.

ISSUE 2 - delete-service API call times out without making the change.

While attempting to work around Issue 1 by deleting and recreating the service, two consecutive delete-service API calls each timed out after 180 seconds. After each timeout the service still exists normally (confirmed via status/list-services API), not left in a "removing" or pending-delete state, and no deletion appears to be queued server-side.

This is a separate mutation from build scheduling, but given it happens on the very same service/project that is also failing to schedule builds, it raises the question of whether this project/service is in some kind of degraded or stuck state on Railway's backend affecting multiple operations.

What we need:

1. Please check builder-egpkfb (or whichever builder is handling this project) and this project/workspace's build-scheduling queue for why every build is rejected before doing any real work.
2. Please check whether service castan-certidoes-web (929712a9-a7d6-4871-b9a8-da1c4e6608f0) has any internal flag, quota, or stuck state explaining both the instant BUILD_IMAGE failures and the delete-service timeouts.
3. If not quickly identifiable, please help unblock this service directly, or confirm it's safe for us to delete and recreate (our own delete attempts keep timing out, so we've stopped retrying on our own).

Thank you!