a month ago
My deployment shows as "Active" but the Deploy Logs panel only shows "No logs in this time range" — no logs at all, not even the "Starting Container" system message I saw in a previous successful deployment.
The site itself returns "Application failed to respond" (502) when I visit it. HTTP Logs show a mix of 499 and 502 (with 502 responses consistently timing out around 15 seconds) for both GET / and GET /favicon.ico.
This worked correctly 6 days ago (same service, different commit) — that deployment's logs showed normal startup output including Starting Container.
I added print(..., flush=True) statements at the very top of my Python entrypoint module (before any other imports or logic) specifically to debug this, expecting them to appear in Deploy Logs regardless of what happens afterward. They do not appear at all, even after confirming (via the deployment detail page, which correctly shows my latest commit message) that this newer code is what's deployed.
Build Logs complete successfully every time — pip install succeeds, image builds, and image push completes (~130MB). The issue appears to be strictly at container startup / runtime.
Start command is python run.py via Procfile (Railpack build driver). No Dockerfile, railway.json, or railway.toml in the repo.
Could you check on your end whether the container is actually starting, and whether there's a resource limit, queued build, or platform-side issue affecting this deployment?
Project ID: 3feebd6b-4ffa-4afd-8c79-4094b63c2e57
Service ID: 565c5327-613c-4b22-8047-c6bc2ca1c239
Deployment ID: dd9dd2a7-1005-4c9c-8ba1-ff3d36a75b71
2 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
Here are the most likely causes for this issue on Railway:
1. Check Procfile Syntax
If your Procfile contains python run.py instead of web: python run.py Railpack won't register the process type, meaning the web process never actually gets spawned (explaining why no "Starting Container" or print logs appear).
2. Bypass Procfile via Railway Dashboard
Go to Service Settings, Deploy, Custom Start Command in Railway and set it directly to python run.py
3. Verify Host and Port Binding
Ensure your Python app is listening on 0.0.0.0 (not 127.0.0.1 or localhost) and picking up the $PORT variable provided by Railway:
import os
port = int(os.environ.get("PORT", 8080))
app.run(host="0.0.0.0", port=port)
Binding to 127.0.0.1 causes Railway's proxy to time out after 15 seconds with a 502 Bad Gateway error.
4. Force Unbuffered Logs
Add the environment variable PYTHONUNBUFFERED=1 under your Service's Variables tab in Railway to guarantee all stdout/stderr prints stream instantly.
5. Check Service Metrics (silent OOM kill)
Check the Metrics tab during container startup.
a month ago
Update on this issue — checked the Metrics tab with a wider time range (1 day instead of 1 hour, since the 1h view showed a flat/empty graph that made it look like the container never started).
With the 1-day view, I can see:
32 requests total, most returning 4xx or 5xx status codes
Response Time graph sits near 15 seconds for most requests
Memory usage does show some activity (steps up to ~100MB at times), so the container does appear to start and consume some resources — it's not completely flat
However, Deploy Logs for the current deployment still show only:
Stopping Container
No "Starting Container" message, no application output at all (I added print(..., flush=True) statements at the very top of my Python entrypoint specifically to debug this, and set PYTHONUNBUFFERED=1 as an env var — neither shows up in Deploy Logs).
Also worth noting: the Deploy Logs panel for this deployment has no time-range selector (unlike the Metrics tab), so I can't rule out a display/retention issue on that panel specifically.
This makes me unsure whether the root cause is:
(a) the container starting but crashing/hanging before any log output is flushed, or
(b) a logging pipeline issue specific to this service/deployment that's unrelated to my application code
Would appreciate any insight into which of these is more likely, or how to get more visibility into what's happening between container start and the "Stopping Container" message.