13 days ago
Service: hritik-coindcx-server2 (project 45ddac0c-d83d-467d-b9ae-469cfd87fa61)
URL: web-production-a1b1.up.railway.app
Region: EU West (Metal / Amsterdam) · 1 replica · python@3.10.14
Active deployment: ce94e1e ("force rebuild") — status ACTIVE, "Deployment successful", Online.
Summary: Every HTTP request to the public URL returns 500 Internal Server Error, but the container is healthy and the deployment is Active. The 500 appears to be generated by the Railway edge, not my app — the edge cannot route requests to the container.
Evidence the response is edge-generated, not from my app:
Request to the live URL:
curl -i https://web-production-a1b1.up.railway.app/health
HTTP/2 500
content-type: text/plain; charset=UTF-8
date: Wed, 24 Jun 2026 19:27:58 GMT
Internal Server Error
Note: content-type: text/plain and no Server header. My Flask app does not produce that shape.
The identical commit run locally returns a correct response:
curl -i http://127.0.0.1:5055/health
HTTP/1.1 200 OK
Server: Werkzeug/3.1.6 Python/3.10.14
content-type: application/json
{"positions":0,"status":"ok","time":"2026-06-25T03:25:08.961199"}
So the application boots cleanly and serves 200 on the same code; /health has no external dependencies (no DB, no third-party API). The container is Active/Online. The failure is in the path between the edge and the container.
Additional context:
This began roughly 18:50 UTC on 2026-06-24. The same code on a fresh worker served traffic normally from ~16:16 UTC for ~2.5 hours before this started; nothing about the deployment changed.
A restart and a fresh rebuild (ce94e1e) did not resolve it.
App-level logs show no exceptions in the failure window — consistent with the requests never reaching the application.
My dashboard is showing the "Logs and metrics may be slow to load — we have identified the incident" banner.
Want to know:
Is this service in the blast radius of the current incident, or is it a separate issue with my service specifically?
Is the EU West edge / request routing affected?
Is there an ETA, or should I relocate the service to another region as a workaround? (My web-volume is in EU West, so I'd appreciate confirmation before detaching it.)
Pinned Solution
12 days ago
i tried that url and i think it now worked
Attachments
2 Replies
13 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 13 days ago
12 days ago
i tried that url and i think it now worked
Attachments
12 days ago
Solved:
i had a hardcoded entry in /etc/hosts pinning web-production-a1b1.up.railway.app to 151.101.2.15. it was force-routing every request for that hostname to that fixed IP, which is wrong/stale (and the DNS flush didn't help because /etc/hosts overrides DNS entirely). the real DNS answer was something else, completely different from the pinned 151.101.2.15. That 151.101.x address is a Fastly range — almost certainly a leftover from some past debugging or a workaround I added and forgot about.
my phone has no such hosts entry, so it resolves correctly and gets 200. My laptop hits the stale pinned IP and gets a 500 that has nothing to do with my server. The server was likely fine for longer than we thought — every test I ran from this laptop was poisoned by this line.
removed that line from /etc/hosts.
sudo nano /etc/hosts
Deleted the line 151.101.2.15 web-production-a1b1.up.railway.app, save (Ctrl-O, Enter), exit (Ctrl-X). Then:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
curl -i https://web-production-a1b1.up.railway.app/health
it did finally return 200.
Status changed to Solved brody • 12 days ago