To resolve this deadlock and pass the healthcheck successfully, implement the following end-to-end working solution:

1. Decouple Database Migrations via Railway's Release Phase

Running blocking pre-flight scripts (python -m app.db_admin prepare) directly inside your main container start command can cause race conditions with the platform's initial port-binding and healthcheck window.

Move the database migration command out of the start command entirely and into a dedicated Release Phase configuration (or run it natively via Railway's project settings as a pre-deploy build step). This guarantees that when your web container boots, it runs only the ASGI server as PID 1 immediately.

1. Fix Container Entrypoint & Port Binding Configuration

Update your service's start command (or Procfile/Dockerfile entrypoint) to ensure standard shell-form expansion of the dynamic $PORT variable. Replace your current start command with a robust shell script pattern that guarantees correct execution and stream flushing:

Bash

python -u -m app.db_admin prepare && exec uvicorn app.main:app --host 0.0.0.0 --port ${PORT:-8000}

python -u: Forces unbuffered binary stdout and stderr streams so that Python logs flush immediately to the host logging pipeline without getting trapped in buffer blocks.

${PORT:-8000}: Provides a safe fallback port if the platform variable injection ever experiences a temporary evaluation race.

1. Add an Explicit Startup Event Hook for Fast Probing

To ensure Uvicorn answers the /health probe instantly upon binding to the network socket, implement an explicit application startup event in your FastAPI app.main file so the health router responds immediately even before background worker threads complete warm-up:

Python

from fastapi import FastAPI

app = FastAPI()

@app.on_event("startup")

async def startup_event():

# Ensures the app signals readiness immediately upon socket open

pass

@app.get("/health")

async def health_check():

return {"status": "healthy"}

4. Force a Clean Cache Redeploy

Once the updated configuration is saved:

Trigger a fresh deployment by pushing an empty commit or utilizing the Redeploy option in the Railway dashboard.

This forces the platform to provision a clean container instance away from the degraded builder node (builder-oersqr), clearing out any hung socket states and re-establishing correct log streaming pipes.

I have seen similar issues where someone trying to run two commands but only the first one executed

Try wrap your start command in a shell like this

sh -c "python -m app.db_admin prepare && exec uvicorn app.main:app --host 0.0.0.0 --port $PORT"

1. try: uvicorn app.main:app --host 0.0.0.0 --port 8000

(sometimes i have also problem with $PORT.)

1. Confirm Uvicorn is listening on 0.0.0.0:8000.

2. Make sure /health is accessible without authentication.

Hey! It's been a while since you posted, so hopefully you've found this already. I was able to reproduce your failure on a test service, and I think a good place to start is going over the questions you had.

Service checks

1. In my test $PORT is injected as PORT=8080, uvicorn bound 0.0.0.0:8080, and the probe reached it from 100.64.0.2 with 200 OK. --host 0.0.0.0 is right, and you do not need --host :: for the healthcheck. Worth saying since it came up above: don't hardcode 8000 or use ${PORT:-8000} — that would create the very mismatch you were asking about.

2. I ran one image twice, healthy and never-healthy, printing to stdout and stderr every 2 seconds for three minutes. Both delivered all 90 lines, in both panes, during the failure and after it was marked failed. I wouldn't lean hard on the first second of output either way, but a three-minute silence is the process not writing rather than Railway not delivering.

3. builder-oersqr is not in this path. Your builds succeeded every time, and the failure happens after the container starts. sardarmudassaralikhan is right that nothing binds a port until the pre-flight step finishes — but your Alembic step completes and prints, so moving it out will not change this.

So to frame the issue: something in your startup path blocks and never returns, so uvicorn never reaches the point where it prints its banner or opens a socket. The healthcheck then gets connection refused, which Railway reports as service unavailable.

Two things in your own post support that. Uvicorn running on … prints last, because the socket is opened last — so no banner means nothing is listening, which is why 300s and 1800s behaved identically. And the same commit worked at 14:43 and hung at 14:47, so whatever changed is outside the image. You restarted Postgres twice in that window, which fits: a startup call that dials the database returned at 14:43 and stopped returning at 14:47.

Your Alembic step working doesn't clear the database either, incidentally. Alembic runs on a sync driver (psycopg2) and your app on an async engine (asyncpg), often against different URLs — two separate connections, so one can succeed every time while the other hangs.

The best hint we have is where your logs stop, which you've narrowed to just after the Alembic migration check. So let's make the process tell you where it is stuck.

Fix

1. Add these two lines at the very top of app/main.py, above every other import:

   
   import faulthandler
   
   faulthandler.dump_traceback_later(15, repeat=True, exit=False)
   

2. Deploy. Every 15 seconds the deploy log gets a traceback of where it is stuck. Mine, from a container blocking on a connect at module level:

   
   Timeout (0:00:15)!
   
   Thread 0x00007fe2da736740 (most recent call first):
   
     File "/root/.nix-profile/lib/python3.12/socket.py", line 850 in create_connection
   
     File "/app/hangmod.py", line 5 in <module>
   
     File "<frozen importlib._bootstrap>", line 488 in _call_with_frames_removed
   
     File "<frozen importlib._bootstrap_external>", line 995 in exec_module
   
     File "<frozen importlib._bootstrap>", line 935 in _load_unlocked
   

   Read down past the standard-library frames: the first File line pointing at your own code is the one to fix — /app/hangmod.py above, not socket.py. With asyncio the top frame is usually the event loop, so it is never the interesting one. The <frozen importlib._bootstrap> frames underneath mean it is blocking at import, which also tells you your startup handler never ran — and explains why your raw stderr write printed nothing. If those frames are absent and you see your own startup function instead, the block is inside the handler.

   I tested this on a deployment that never becomes healthy — it still reports.

3. Fix according to what that line names:

   • Your own module-level code — an engine created at import, a pool warm-up, a client, a secrets fetch. Move it into the startup handler and bound it:

     
     @asynccontextmanager
     
     async def lifespan(app: FastAPI):
     
         app.state.engine = create_async_engine(DATABASE_URL, connect_args={"timeout": 10})
     
         await asyncio.wait_for(app.state.engine.connect(), timeout=15)
     
         yield
     
     app = FastAPI(lifespan=lifespan)
     

   • A third-party module that connects while being imported. You cannot move code you do not own, so stop importing it at module scope — move import x inside the function that uses it — or pass that library an explicit connect timeout.

   • Already inside your startup handler. Leave it there and wrap the call: await asyncio.wait_for(..., timeout=15).

4. If that line is a database connect, compare the URL your app builds with the one app/db_admin.py hands Alembic. You are looking for a different host, not a different driver prefix — postgresql+asyncpg:// vs postgresql:// against the same host is normal. A public or proxy host on one side and *.railway.internal on the other, or a hardcoded address, is the discrepancy worth finding.

Add the timeout even once the endpoint is healthy again. An unbounded network call at import turns any slow dependency into this exact failure: live process, no logs, healthcheck that can never pass. With one, you get a traceback and a deploy that fails in seconds instead of 30 minutes.