n8n service Online but Console WebSocket failed + all outbound ETIMEDOUT
rozza84
HOBBYOP

25 days ago

My n8n service on Railway shows as "Online" but has the following issues:

  1. Console tab shows "WebSocket connection failed" – cannot connect at all

  2. All outbound HTTP requests from n8n fail with ETIMEDOUT

    (e.g. connect ETIMEDOUT 188.40.99.226:443 to api.open-meteo.com)

  3. GitHub source repo suddenly shows "GitHub Repo not found"

    without any changes on my end

Deployment ID: 22007e7a

Project: n8n (n8n-production-981e.up.railway.app)

This started without any changes on my side.

The service was working fine previously.

image.png

Attachments

$10 Bounty

3 Replies

Railway
BOT

25 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway 25 days ago


Try redeploying the service.


mirajtradersglobal
FREE

23 days ago

Fix attempt: Redeploy the n8n service from Railway Deployments.

If still failing: Reconnect GitHub source and deploy latest commit.

If outbound requests still show ETIMEDOUT: escalate to Railway as an infrastructure/networking issue and ask them to move or repair the deployment host/region.

Most likely root cause: Railway-side egress/network/control-plane problem, because inbound WebSocket, outbound HTTPS, and GitHub source detection all failed at the same time.


lleywyn
PROTop 5% Contributor

23 days ago

The fact that inbound websocket, outbound HTTPS, and GitHub all broke at the same time with no changes on your side points to a platform networking issue, not your config....prooobably one of those failing could be you, all three at once is the host, who knows kek

do this in order, as described above..

  1. Redeploy first. That moves you to fresh infra and clears most spontaneous networking glitches like this.

  2. Once it's back, reconnect GitHub and deploy the latest commit so the source link refreshes.

  3. Test outbound again, the open-meteo timeout on 443 is the clearest signal. If ETIMEDOUT is still happening after a redeploy, it's not your code.

If it survives the redeploy, escalate to Railway as an infrastructure/networking issue and give them the deployment id (22007e7a) and project.

If you escalate, be sure to mention the simultaneous inbound plus outbound plus GitHub failure, that pattern tells them to look at the host or region rather than your service.


Welcome!

Sign in to your Railway account to join the conversation.

Loading...