4 days ago
Service: portal-minsup
Project: has linked Postgres and Redis services (both Online)
Issue: Deployments intermittently fail the healthcheck at /api/health even when the application demonstrably boots successfully.
What we've verified:
- Built the exact same Dockerfile image locally (outside Railway) and ran it with the production DATABASE_URL and REDIS_URL — it boots in ~15s and /api/health returns 200 OK consistently.
- On Railway, deploys of the identical commit/image are inconsistent:
- Some deployments show full successful boot in Deploy Logs (NestJS "Nest application successfully started", all routes mapped, "🚀 Minsup API running on http://localhost:8080/api" printed) — yet the healthcheck still fails for the entire 5-minute retry window and the deployment is marked Failed.
- Other deployments of the same image never print any application output at all after the container starts — not even framework-level logs that require no network access — and again fail the healthcheck for the full window.
- We already ruled out and fixed several real bugs on our end during this investigation (wrong entry point path, prisma CLI losing its engine binary after
npm prune, migrate deploy chained into the start command instead of using the pre-deploy step). None of these fully explain the remaining intermittent behavior. - PORT (8080) matches the configured Target Port in Networking.
- Region has changed between deploys without us changing it (observed both "US East (Virginia)" and "US West (California)" for the same service across consecutive deployments).
- We've also observed dashboard state inconsistencies across this session: the public domain disappearing (service showing "Unexposed service") and regenerating on its own, environment variables briefly showing as completely empty (0 custom variables) despite being previously configured, and the Builder setting switching from "Dockerfile" to "Railpack" without manual action.
Deployment IDs for reference: 97eb1c0f, a975f9df, fec69a2d, 5302ba68
Given the same image is verified working outside Railway, and behavior is inconsistent across otherwise-identical deploys within Railway, this looks like an infrastructure-side issue (networking between the healthcheck prober and the container, or service state corruption) rather than an application bug. Would appreciate help investigating from your side.
3 Replies
4 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 4 days ago
mayori
You need to bind the hostname to `0.0.0.0` instead of `localhost` as documented [here](https://docs.railway.com/networking/troubleshooting/application-failed-to-respond#application-not-listening-on-the-correct-host-or-port)
4 days ago
Thanks! That's actually the Railway-documented most common cause (https://docs.railway.com/guides/... "Application failed to respond"), and we already have it in place exactly as documented:
const port = config.get('PORT', 3002);
await app.listen(port, '0.0.0.0');
We can also confirm from the Deploy Logs that this is working correctly — one of our successful boots logged "[BOOT] 4/5 listening on port 8080", matching the configured Target Port of 8080 exactly. So host/port binding isn't the issue here; the healthcheck still fails afterward even when the app is confirmed listening on the right host:port. That's what makes this one confusing — it doesn't match the usual "Application failed to respond" root cause.