18 hours ago
Service: arise-os (project c14ca9b1-a9fe-4f64-9ee6-790085a7a413, service edadb862-fe20-4249-8520-27d4b16714c6, environment 57f0ebd0-81df-4f74-adb0-11b6b32e7ae1), Next.js app deployed via GitHub (AriseAbove/arise-os-private, branch rebuild/arise-above).
Issue: The last 3 deploy attempts of the same commit (daac5ea) have failed identically at "Network > Healthcheck" — the deployment sits for the full 5-minute Healthcheck Timeout with zero response ever reaching the configured Healthcheck Path (/api/health), then fails. Deploy logs show the app booting cleanly and the process running fine internally (I can see repeated successful internal log lines for several minutes) — it's specifically the healthcheck prober that never gets a response.
Failed deployment IDs: 72b79692-f1c9-450f-a39f-67c016479212 and 70f1efdf-8824-4ca4-ace9-3feb32d95f25 (both same commit, both identical failure).
What I've already ruled out:
- App-level bug: I built and ran the exact same commit locally (production mode, same start command) and /api/health responded correctly in under 150ms on every request, repeatedly.
-
- Healthcheck config: Path (/api/health) and Timeout (300s) are both correct and unchanged from previous successful deploys.
-
- Platform incident: status.railway.com shows fully operational, no incidents.
-
- Railway's own "Diagnose" AI tool on the failed deployment could not identify a cause.
The currently-live deployment (a different, earlier commit, same service/config) is healthy and has been serving traffic fine for 12+ hours, so this isn't a config issue with the service overall — it's specific to redeploying this particular commit. Would appreciate help figuring out why the healthcheck prober can't reach this deployment. Happy to provide more logs/details.
2 Replies
18 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 18 hours ago
15 hours ago
Thanks for digging in! I checked the binding-address angle you raised and can rule it out on two counts:
- Start command is
next start -p 4100(package.json) — no custom server.js/standalone output mode, so it's not the process.env.HOSTNAME behavior you described. Plainnext startbinds 0.0.0.0 by default with no -H override. - Service Settings > Networking > Target Port is set to 4100, matching the start command exactly — no port mismatch.
So the app should be listening correctly on the right interface/port. The healthcheck is still timing out at exactly 300s (matches the configured Healthcheck Timeout) with zero response reaching the app logs during that window — build and container start both succeed per the deploy log, it's specifically the Network > Healthcheck phase that hangs. Healthcheck Path is /api/health, which does a real DB round-trip but responds in milliseconds locally and in prior successful deploys on this same service/branch with no code changes to routing, middleware, or the health route itself.
Given port and binding both check out, does this look more like something on Railway's edge/proxy side for this specific deployment attempt? Happy to share deploy IDs or logs if useful.
12 hours ago
That was it — solved. PORT was not set as a service variable at all; only the Networking "Target Port" was configured to 4100. Added PORT=4100 explicitly, redeployed the same commit, and it went ACTIVE / "Deployment successful" this time. Confirms your point exactly: Target Port and PORT are separate, and Railway's healthcheck prober relies on PORT. Appreciate you working through this with me — marking solved.