a day ago
Website is up but my email server which is on seperate railway island or whatever we call it, its throwing 502 error
Application failed to respond
This error appears to be caused by the application.
If this is your project, check out your deploy logs to see what went wrong. Refer to our docs on Fixing Common Errors for help, or reach out over our Help Station.
If you are a visitor, please contact the application owner or try again later.
Request ID:
2D_HBXh_SPGm_qgBAQeqjw
4 Replies
a day ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 22 hours ago
a day ago
This may be related to Railway’s May 19/20 platform recovery, but the error shown is specifically Railway’s HTTP proxy saying the application did not respond.
A couple of things to separate first:
- If this is actually an email server using SMTP/IMAP/POP3, a normal Railway public HTTP domain will not work for those protocols. You need TCP proxying for non-HTTP ports, not an HTTP domain.
- If this is a webmail/admin UI for the email server, check that the process is still running and listening on the expected HTTP port.
- In the service logs, look around the timestamp of request id
2D_HBXh_SPGm_qgBAQeqjw. - If this worked before the May 19/20 incident and no config changed, try a normal redeploy/restart once. Railway’s incident report says routing, deploys, and queued recovery were affected after the GCP account suspension.
If logs show the service is healthy and listening, then this may be leftover routing/recovery fallout and the request id is useful for Railway support.
Incident report:
https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage
TCP proxy docs:
ve-jo
This may be related to Railway’s May 19/20 platform recovery, but the error shown is specifically Railway’s HTTP proxy saying the application did not respond. A couple of things to separate first: 1. If this is actually an email server using SMTP/IMAP/POP3, a normal Railway public HTTP domain will not work for those protocols. You need TCP proxying for non-HTTP ports, not an HTTP domain. 2. If this is a webmail/admin UI for the email server, check that the process is still running and listening on the expected HTTP port. 3. In the service logs, look around the timestamp of request id `2D_HBXh_SPGm_qgBAQeqjw`. 4. If this worked before the May 19/20 incident and no config changed, try a normal redeploy/restart once. Railway’s incident report says routing, deploys, and queued recovery were affected after the GCP account suspension. If logs show the service is healthy and listening, then this may be leftover routing/recovery fallout and the request id is useful for Railway support. Incident report: https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage TCP proxy docs: https://docs.railway.com/networking/public-networking
15 hours ago
it was working before 19/20
13 hours ago
Adding to ve-jo's points — after the May 19/20 incident, we found our Postgres hosting URL had changed and connected services were still pointing to the old one. Redeploying Postgres and the dependent services fixed it. Might be worth checking trying a full redeploy.
an hour ago
Your Server service has had 4+ consecutive healthcheck failures since May 20th, with no application logs produced. This is consistent with a stale container image after the May 19/20 platform recovery. Your Postgres, Redis, MinIO, Storage, and Console services are all running fine - only the Server service needs attention.
Open the Server service, and trigger a redeploy- that should bring things back into a good state.
Status changed to Awaiting User Response Railway • about 1 hour ago
Status changed to Open mykal • about 1 hour ago