Hi Railway team, I've been experiencing persistent dashboard "canvas loading slowly" messages and Railway CLI timeouts for the past several days. After investigation, the issue appears to be a routing problem between the Cloudflare JNB (Johannesburg) PoP and Railway's backend. Symptoms: * Dashboard canvas fails to load or loads very slowly (\~50% of the time) * railway status, railway logs, and other CLI commands timeout * Issue has been ongoing since approximately 2 April Diagnosis: * TCP connection to [backboard.railway.com](http://backboard.railway.com) fails \~50% of attempts from JNB * Both Cloudflare IPs affected (104.18.24.53, 104.18.25.53) * Successful connections complete in 6-9ms; failed connections hang 13-88s before timeout * [railway.com](http://railway.com) (marketing site, different Cloudflare zone) works perfectly from the same network * Deployed apps on \*.[up.railway.app](http://up.railway.app) respond normally (425ms, HTTP 200) * cf-ray header confirms JNB PoP; via: 1.1 google header on backend responses Environment: * Location: Johannesburg, South Africa * Railway CLI: v4.35.2 * ISP: Supersonic * No VPN or proxy This appears to be a Cloudflare-to-origin routing issue specific to the JNB PoP, since the application hosting edge is unaffected and only the GraphQL API ([backboard.railway.com/graphql/v2](http://backboard.railway.com/graphql/v2)) drops connections. Regards, Tyrone Niland

Intermittent, frequent TCP connection failures to backboard.railway.com from Johannesburg, South Africa

devteej

HOBBYOP

2 months ago

Hi Railway team,

I've been experiencing persistent dashboard "canvas loading slowly" messages and Railway CLI timeouts for the past several days. After investigation, the issue appears to be a routing problem between the Cloudflare JNB (Johannesburg) PoP and Railway's backend.

Symptoms:

Dashboard canvas fails to load or loads very slowly (~50% of the time)
railway status, railway logs, and other CLI commands timeout
Issue has been ongoing since approximately 2 April

Diagnosis:

TCP connection to backboard.railway.com fails ~50% of attempts from JNB
Both Cloudflare IPs affected (104.18.24.53, 104.18.25.53)
Successful connections complete in 6-9ms; failed connections hang 13-88s before timeout
railway.com (marketing site, different Cloudflare zone) works perfectly from the same network
Deployed apps on *.up.railway.app respond normally (425ms, HTTP 200)
cf-ray header confirms JNB PoP; via: 1.1 google header on backend responses

Environment:

Location: Johannesburg, South Africa
Railway CLI: v4.35.2
ISP: Supersonic
No VPN or proxy

This appears to be a Cloudflare-to-origin routing issue specific to the JNB PoP, since the application hosting edge is unaffected and only the GraphQL API (backboard.railway.com/graphql/v2) drops connections.

Regards,

Tyrone Niland

2 Replies

Status changed to Awaiting Railway Response Railway • about 2 months ago

brody

EMPLOYEE

2 months ago

Thanks for the thorough diagnostics. The routing between your ISP and Cloudflare's JNB PoP is controlled by Cloudflare, not by us, so this isn't something we can fix on our end. We'd recommend reporting the issue to Cloudflare directly, as they manage which PoPs serve traffic and how connections are routed through their network. You could also try reaching out to your ISP (Supersonic) to see if they can investigate the path to Cloudflare's JNB edge.

Status changed to Awaiting User Response Railway • about 2 months ago

brody

Thanks for the thorough diagnostics. The routing between your ISP and Cloudflare's JNB PoP is controlled by Cloudflare, not by us, so this isn't something we can fix on our end. We'd recommend reporting the issue to Cloudflare directly, as they manage which PoPs serve traffic and how connections are routed through their network. You could also try reaching out to your ISP (Supersonic) to see if they can investigate the path to Cloudflare's JNB edge.

devteej

HOBBYOP

2 months ago

Ok, will do. Thanks for the quick response.

1