4 days ago
Summary
On 2026-10-01, from about 02:40 UTC until at least 04:54 UTC, HTTPS requests entering through the sin1 edge stalled for 6–35 s in the TLS handshake and then took about 5 s more to the first byte. TCP connected in 20–40 ms throughout. railway.com showed the same stall from the same network. At about 05:09 UTC everything returned to normal: handshake 0.07–0.15 s, first byte 0.26–0.36 s. Our service and database were idle and healthy the whole time. Before the slowdown, at about 02:30 UTC, the same URL answered in 0.3 s.
Fresh check at 05:09–05:10 UTC (recovered)
- https://api.xlate.live/api/health: tcp 0.03, TLS 0.07–0.15, first byte 0.26–0.36 s
- https://railway.com: TLS 0.07 s
- Independent check from 59 locations (check-host.net): 50 OK, median 0.33 s, max 1.41 s; Ho Chi Minh City 0.34 s, Jakarta 0.25 s, Singapore 0.68 s (only Iran and Russia failed)
During the slowdown (02:40–04:54 UTC)
- Everything in the earlier measurements applies: handshake 6.3–35 s for api.xlate.live, our *.up.railway.app address and railway.com, with tcp connect 0.02–0.04 s; backboard.railway.com, Google and our Vercel site instant from the same network; traceroute to 69.46.46.43 was 6 hops, about 10 ms; an independent check between 02:40 and 04:54 UTC timed out from Ho Chi Minh City and Jakarta, with Singapore at 1.9 s.
Our setup
- Custom domain api.xlate.live (CNAME to cj7iw9dk.up.railway.app), headers server: railway-hikari, x-railway-edge: sin1, resolves to 69.46.46.43
- Project ID: Service: Service region: Plan:
Questions
- Was there an incident on the sin1 edge or the 69.46.46.x block between about 02:40 and 05:00 UTC on 2026-10-01, and what was the cause?
- Is there anything we should change on our side (for example how the custom domain is attached) to avoid being affected next time?
- Could status.railway.com cover edge incidents like this one, even when they only affect some regions? It showed everything operational throughout.
Raw curl output available on request.
1 Replies
Status changed to Awaiting Railway Response Railway • 4 days ago
4 days ago
No incident was published on our status page for the 02:40-05:09 UTC window on 2026-10-01. The routing and dashboard incidents posted on 2026-09-30 don't match your timing or symptoms.
Your custom domain is set up correctly. The CNAME points at your service's generated domain, ownership is verified and the certificate is valid. Nothing about how the domain is attached would cause handshake stalls, so there is nothing to change there.
If it happens again, two checks from the affected network will show where the handshake stalls. First, use curl's --resolve flag to send the request to a different edge IP from our range. Second, run openssl s_client against 69.46.46.43 with your generated *.up.railway.app hostname as the -servername. If another IP works, traffic to that one address is being filtered. If the generated hostname completes while your custom hostname hangs on the same IP, something on the path is filtering by hostname. In either case, a proxy or CDN in front of the domain is the lasting fix for users on that network.
Thanks for the suggestion about covering regional edge degradation on the status page.
Status changed to Awaiting User Response Railway • 4 days ago