10 hours ago
Service barra-web in project pirats-bay-bar (region sfo) has had every deployment fail at Network → Healthcheck for ~24 hours now, across multiple attempts (railway up and railway redeploy). Build and Deploy phases complete successfully every time (Build ~56s, Deploy ~8s), then the healthcheck against /salud/ fails with "service unavailable" until the retry window is exhausted (tried both a 100s and a 5-minute window — same result).
I found two similar recent threads here (a Gunicorn one and the rave/Next.js one where a Railway engineer traced it to the Aug 28 no-redirect-follow change) and already ruled out both of their root causes for my case:
Not a binding issue: my start command is gunicorn barra.wsgi:application --bind 0.0.0.0:$PORT, and railway ssh'd in to confirm — curl http://127.0.0.1:$PORT/salud/ and curl http://0.0.0.0:$PORT/salud/ both return 200 directly.
Not a redirect: those same curl calls were run without -L, and still returned 200 (not 301/302) — so the no-redirect-follow policy change from Aug 28 doesn't apply here, /salud/ is a plain 200 with no redirect involved.
DB is healthy: connects in ~51ms, 11/100 connections used.
Not app-level: same image/container, run manually, serves /salud/ correctly within 3 seconds.
Not usage/billing: workspace well under any limit.
The currently-live deployment (unchanged code, same service) keeps serving traffic fine throughout — it's specifically new deployments that never pass the healthcheck. This looks like the same "network wiring never completes for a new container" class of issue as the threads above, just without a redirect or binding cause behind it in my case. Happy to share deployment IDs / run any diagnostic you'd like.
1 Replies
10 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 10 hours ago
4 hours ago
Railway's healthcheck only confirms a successful deployment if the configured path is accessed and an HTTP 200 response is received; a successful build does not guarantee the application is ready to accept requests.
Check that the healthcheck path truly exists, for example, /health; it should not require login and should not return 301/302/401/404/500 errors.
The application must listen on the port injected by Railway and bind to 0.0.0.0, not localhost or a hardcoded port.
If the service restricts the Host header, healthcheck.railway.app must be allowed; otherwise, a 400 error or "service unavailable" will occur.
Check the deployment logs to identify: Application not started/crashed; Inconsistent port or target port; Slow or failed initialization of database dependencies (e.g., /health).
If the application requires a longer startup time, increase the healthcheck timeout; the default is 300 seconds.