Subject: New service deployments exit within seconds of container start — reproduced across 2 projects, 2 deploy methods, isolated from application code

Account: adiabraham@uchicago.edu (workspace: adiabraham2028's Projects)

Summary

Every deployment I create in this workspace starting July 22, 2026 fails the same way: the container starts, runs briefly (a few seconds at most — even a bare sleep 300 doesn't survive), and exits with no crash signal, no error in logs, and no OOM/CPU spike. Meanwhile my 3 other projects in the same workspace, all deployed before July 22, are running fine right now with no changes.

Affected

• Project resident-signal (ID 41299c68-b3ce-4394-9bf3-1ac179b8ad0a), service resident-signal (ID f9161dca-803b-4099-967b-c1a482ebbb01), region sfo. Created 2026-07-22T23:59:20Z.
• Project resident-signal-v2 (ID 1da30983-3188-42ea-a3ab-1fc6226d834d), service backend-v2 (ID c4eebb20-1a0a-43f3-bc31-17f4fba3bbf2), region sfo. Created 2026-07-23T16:40:37Z. Created as a from-scratch isolation test — fresh project, fresh Postgres, fresh GitHub-connected service — and failed identically.

Unaffected (for comparison, same workspace, same account)

• gentle-encouragement (created 2026-06-25) — services industrious-empathy, underwriting-platform — both running: 1 right now.
• focused-tranquility (created 2026-06-26) — service capital-crm — running.
• delightful-courage (created 2026-07-08) — service prediction-market-indices — running.

All are GitHub-connected Dockerfile-builder Python/FastAPI services in region sfo, same general shape as the affected services.

The decisive test

I set the start command (confirmed via the deployment's own fileServiceManifest.deploy.startCommand in the API, not just the file) to:

echo ALIVE_TEST_START && sleep 300

This has zero dependencies, no port binding, no database connection, no imports — nothing that could fail on our side. Deployment 928f07b3-2c6b-4dc1-b0ea-920e47dc97de (project resident-signal-v2) ran this. I checked its replica status ~2 minutes after creation, well inside the guaranteed 300-second window:

status: SUCCESS
replicas: {"configured": 1, "running": 0, "crashed": 0, "exited": 1, "total": 1}

The container exited on its own within 2 minutes of running sleep 300. There is no way for that command to exit early on its own.

What I've ruled out

• Application code / dependencies: the exact same Docker image (built from this repo's Dockerfile) runs perfectly in local Docker on my machine, connected to a real (also-local, but network-reachable) Postgres instance — /health returns 200 immediately.
• Deploy method: reproduced identically via CLI path-based upload (railway up) AND via a GitHub-connected deploy (railway service source connect), including a deploy YOU triggered manually from the dashboard, not via the CLI.
• Config drift (railway.json / Dockerfile): compared directly against a currently-working sibling project's deploy config (underwriting-platform, same account) — differences exist (their restart policy isn't overridden, their CMD uses JSON-array form vs our shell-form) but neither explains a sleep 300 dying, since our diagnostic test used neither alembic, uvicorn, nor $PORT substitution at all.
• Billing / spending cap: confirmed via the dashboard that billing is usage-based (no hard cap blocking overage), current cycle usage is $5.14, card is on file.
• Memory/OOM: memory graph is flat, no spike, for the affected deployments.
• Healthcheck killing it: healthcheckPath is null for the affected service (confirmed via API) — no active healthcheck is configured to be failing.
• Serverless/scale-to-zero: sleepApplication: false — not serverless.
• Railway status page: checked, nothing reported.

What's still unexplained

Both failing projects were created July 22–23, 2026. All working projects predate that. I have no visibility into what changed on my account or on Railway's infra around that date — that's exactly what I'm asking you to check.

Ask

Please check:

1. Whether this workspace/account has any resource allocation restriction, verification hold, or provisioning-pool assignment that started around 2026-07-22.
2. Whether there was any infra change, rollout, or incident affecting new-service compute provisioning in region sfo around that date.
3. Deployment 928f07b3-2c6b-4dc1-b0ea-920e47dc97de specifically — what killed a container running only sleep 300?

Happy to provide any further deployment IDs, logs, or reproduce anything else you need.