a month ago
Hello,
we are seeing intermittent 502 Application failed to respond on our production web service.
What we observed:
We received an outage notification about a hardware failure affecting our service host.
The app container starts successfully and healthcheck endpoint returns 200.
Despite healthy startup, edge requests still intermittently return 502.
Error patterns include connection dial timeout and connection refused.
This happens on basic routes (/, /favicon.ico) as well, not only on heavy endpoints.
What we already changed on our side:
Confirmed app binds to PORT correctly.
Added healthcheck path and fixed HTTPS redirect behavior for health probes.
Increased process resilience (multiple workers in single instance).
Why we think this may be platform/routing related:
App-level healthcheck is green.
Failures occur at edge-to-upstream connection stage.
Issue started in the same period as reported host outage.
Could you please check:
Whether our service is still attached to affected infrastructure.
If there is stale edge routing to old/unhealthy instance.
Any platform-side incident still impacting this region/environment.
Thanks.
5 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
0x5b62656e5d
Try redeploying your service.
a month ago
Doesn't work...
a month ago
Try changing the port number of your application and URL(s) to an arbitrary number (eg, 4100) and see if that works.
0x5b62656e5d
Try changing the port number of your application and URL(s) to an arbitrary number (eg, `4100`) and see if that works.
a month ago
Thanks for the suggestion.
I tested it by remapping to port 4100 and redeploying. Healthcheck passes (/health/ = 200), but intermittent 502s still happen on basic routes (/, favicon) in 1–2 ms.
So port configuration is not the root cause; this looks like an edge/routing/platform issue.
a month ago
Update: issue is resolved now.
What I changed:
Fixed Railway healthcheck by exempting /health/ from HTTPS redirect in settings_railway.py:180.
Kept app startup on dynamic PORT and multi-worker Uvicorn (resilience hardening).
Tested custom public port mapping (4100) and confirmed it was not the root cause.
Moved region and then switched back to EU; service is now stable again.
What I observed:
Deploy and healthcheck are green.
Requests to /health/ return 200.
502 pattern matched platform/routing instability rather than app code regression.
Thanks everyone for suggestions.
Status changed to Solved 0x5b62656e5d • about 1 month ago