@Phineas - what kind of information would we need to debug this further?

Request/response data (headers, status codes, body) from failures would be ideal

It doesn’t look like we’re even able to make an HTTP handshake, it fails before that.

Could I seee an example error (guessing this is Sentry)?

Do you have any details about the client (IP, country)?

And have you seen any patterns in behavior - e.g. are all the errors caused by one client, or one country?

Yep, all our userbase are Brazilians and we do have their IP (Sentry send us those)

One repeated pattern is that one specific endpoint fails more often than the others, which is the one we are using to validate the issue.

Let me see if I can find any pattern on ISPs

This is xhr.onerror so it could legitimately be any layer, tcp/tls/dns/http

It's not enough itself to know how a request failed. I slightly remember Sentry offering some sort of network request logging, do you know if you have that enabled?

Seems like we have it, but it's pretty basic

I knew we should have migrated this to our OTEL warehouse too 😭

Could I get an IP address/ASN from one of these failures?

It'd help rule out a bad route from some huge brazilian ISP

We have three people from our team that was suffering from it too, all of them have different ISPs. Two of them are small city ISPs and one is from a big ISP.

Here's mine:

• 18881 - AS18881 (a big one)

Will get the ASN from the others.

They might all upstream to 18881

• 52908 - AS52908
• 269168 - AS269168

Yep, could be

I've just replied on the thread - we've replicated this across a few regions

To confirm, you only saw this at 8:09pm BST as per your screenshot, right?

Hi Phineas

I'll pull the full trace now, the one that triggered our status page was at that time but will confirm. Our status page does also wait before alerting.

We've checked and can see that the get request to show the page didnt make it to our backend from railway (backend is in gcp)

If helpful @Phineas

  "message": "GET 522 / dynamic (19540ms)",
  "level": "error",
  "cache_hit": false,
  "client_tcp_rtt_ms": 0,
  "cache_bytes": 1697,
  "cache_status": "dynamic",
  "edge_start": "2026-06-06T19:08:40Z",
  "cache_reserve_used": false,
  "client_device": "desktop",
  "client_country": "au",
  "client_ip": "[REDACTED_CLIENT_IP]",
  "client_city": "Sydney",
  "response_body_bytes": 0,
  "referer": "",
  "client_asn": 63949,
  "client_lat": "[REDACTED_LAT]",
  "edge_colo": "SYD",
  "dt": "2026-06-06T19:08:59Z",
  "origin_tls_version": "none",
  "cache_tiered_fill": false,
  "method": "GET",
  "origin_ip": "[REDACTED_ORIGIN_IP]",
  "host": "hub.example.com",
  "scheme": "https",
  "user_agent": "Better Stack Better Uptime Bot Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36",
  "uri": "/",
  "origin_header_send_ms": 0,
  "path": "/",
  "protocol": "HTTP/2",
  "tls_version": "TLSv1.3",
  "client_lon": "[REDACTED_LON]",
  "status": 522,
  "origin_header_recv_ms": 0,
  "origin_tcp_ms": 0,
  "waf_sqli_score": 97,
  "waf_score": 87,
  "waf_xss_score": 97,
  "waf_rce_score": 90,
  "origin_response_ms": 0,
  "ray_id": "[REDACTED_RAY_ID]",
  "zone": "example.com",
  "security_action": "",
  "edge_server_ip": "[REDACTED_EDGE_IP]",
  "origin_tls_ms": 0,
  "tls_cipher": "AEAD-AES256-GCM-SHA384",
  "ttfb_ms": 19540,
  "response_bytes": 368,
  "content_type": "",
  "origin_dns_ms": 279,
  "origin_status": 0
}```

We saw this yesterday too - heres the full set over the last 2 days.

@ThallesComH This happened to me too. See what I did. https://discord.com/channels/713503345364697088/1512622705092858177

https://tenor.com/qyqyvap64W0.gif

page me when it happens again <:Fingers:1202140286956867644>

I am too, getting this

That is unrelated I believe; the routing is ok in this thread's case.

I have a feeling about what could be causing this specifically, and I think it's unrelated to @ThallesComH's issue.

It's two problems in one thread, the second one appears to be the same network issue, no?

The timing in your montiors lines up with when we do a "hard rollout" to the edge proxies, which causes new tcp connections to get NAT'd to a new healthy node temporarily, and I don't think the Cloudflare proxy likes that behavior for some reason. I'll look more into it.

It's unrelated to this specifically, I'll follow up in your thread

Interesting, we’ve only observed this in the last 48 hours - with no issues for 4 weeks prior (well we have had some 522s but not cascading like this)

Let me know if there’s anything else I can help with

Yeah, we recently moved traffic onto new edge proxies which have a different rollout behavior

Okay, happy to share anything you guys need - just @ me as notifications off

@ThallesComH Hey - have you noticed the error rate start to trend down or are you still experiencing this?

We put Cloudflare in front of our backend to solve the issue. I’ll see if I can reproduce it on Monday morning.

Sorry I really forgot about this (was really busy with an outage from an external provider), but this issue really seems related to ours: https://station.railway.com/questions/edge-proxy-drops-idle-keep-alive-connect-8a73c89d.

After awhile we noticed it was Android only and might be related to this, I'll give it a throughly test soon.

cc @Phineas that thread might be the info you needed.

Interesting they seem to be in Brazil too. Thank you for the context