2 months ago
Hi Railway team,
I'm getting recurring, brief 502 Bad Gateway outages on a production service. Each lasts ~8 minutes, they recur every few days with no correlation to my traffic or deploys, and they self-recover.
During each window my container is fully healthy — same instance, no crash, no restart, event loop steady at ~5ms, memory flat — and it keeps serving the requests it manages to receive. Your edge HTTP logs show the failures as connection dial timeout (5000ms, retried 3×) from the edge to the instance, with detail: "Retried single replica", then 502. So the edge can't open a TCP connection to a healthy instance for several minutes, then can again. This looks like an edge↔host networking fault, not my application.
To preempt the usual first questions: the service runs normally outside these windows, so port binding and health-check config are correct — this is purely intermittent edge-to-instance reachability, not a startup, port, or health-check problem.
This matches a prior report your team attributed to a transient regional network issue (station thread: https://station.railway.com/questions/cloudflare-502s-bad-gateway-9d905d08). Since mine recurs every few days, I'd like to understand whether it's a persistent problem with my host/region placement rather than a one-off.
Most recent occurrence: 2026-06-08 21:51:56 → 21:59:50 UTC (~8 min). Edge region observed: asia-southeast1-eqsg3a. I currently run a single replica.
I can provide the project/service/deployment/instance IDs and specific failing request IDs privately, or you can read them off my account.
Questions:
-
Can you inspect the host/networking for my instance during that window and confirm what caused the edge to be unable to dial it?
-
Is this a persistent issue with the host/region my workload is placed on — and can the workload be moved?
-
Beyond adding a second replica for failover, is there anything on my side that reduces exposure?
Thanks,
Jared
1 Replies
Status changed to Awaiting Railway Response Railway • 2 months ago
2 months ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 2 months ago
Status changed to Solved jaredrhod • 2 months ago
a month ago
Your diagnosis seems reasonable based on what you've shared. If your instance remains healthy (no restart, stable event loop, flat memory usage) while the edge is consistently reporting connection dial timeout and Retried single replica, it does point more toward an infrastructure networking issue than an application issue.
A couple of thoughts while you wait for the Railway team to investigate:
- Since you're running a single replica, there's unfortunately no redundancy if the edge temporarily loses connectivity to that host. Running two replicas would at least allow the edge to retry another healthy instance.
- It would be useful if Railway could confirm whether all of these incidents occurred on the same underlying host or placement. If they did, that would strengthen the case for migrating the workload.
- If you have external monitoring (UptimeRobot, Better Stack, Pingdom, etc.), it can help demonstrate that the outages are externally observable and correlate with the timestamps you're providing.
- If you haven't already, I'd also compare the edge logs with your application logs during the affected window. If the app never sees the failed requests, that further supports the idea that the requests are failing before they ever reach your container.
Given the recurring nature of the issue and the previous Station thread you referenced, I think it's worth Railway checking host placement or regional networking during those timestamps. Hopefully they can correlate your request IDs with their internal network logs.
Curious to hear what they find—please update the thread when you get a response.