Hello,
I see issues of my app sine 7:42 UTC today. fly status or fly logs is not working at all:
failed retrieving app my-app: Post "https://api.fly.io/graphql": net/http: TLS handshake timeout
I am wondering why the Fly status page shows that everything is operational…
Same here, fly.io and my app in the FRA region are painfully slow. ~30s response times.
Also getting the TLS handshake timeout error when using flyctl.
It’s FRA for me too. Seems that CDG is working though… Unfortunately I can’t adjust the regions due to the not available fly API…
There’s an entry now - Fly.io Status - Connectivity issues in FRA region
It seems my VM in fra was killed and respawned in cdg a couple of hours ago. This doesn’t help though - I’m seeing request latencies of 10-15s when curling, or opening the app for the first time in Chrome. If I reload the site the load is instant (keepalive?).
Here’s the timeline from Chrome dev tools:
Same,
We’re seeing a lot of network timeouts, across two orgs, and via two different uptime monitoring tools, in LHR.
I have had all apps down for about hour… CLI wasn’t working as well.
Unfortunately have only one region (for each app), but if I had more of them, would the dropout be covered today?
update: something is working, but still have problem with Sockets
WebSocket is closed before the connection is established.
Same here, websockets are not working.
CLI is sometimes working but sometimes I get this error :
Error failed retrieving app hootify-prod: Post "https://api.fly.io/graphql": net/http: TLS handshake timeout
We’re investigating network issues in Frankfurt. It seems like they’ve been off and on overnight (US time), traffic should routing around that region now.
The status page does have updates now, too: https://status.flyio.net/
If App was running on multiple regions … (Scaling and Autoscaling) … would that prevent from complete app downtime by auto re-route traffic to different region or not?
Thank you for info
I was having WebSocket issues while running both in AMS and LHR.
I moved everything to the US where it works (VIN and ATL).
With the caveat that we haven’t completely solved this problem or found the root cause yet, moving apps between regions probably wouldn’t have helped.
The issue we’re having is related to how users enter the network. People in Germany will usually hit our Frankfurt edge, then we send the request to the region your app is running in.
@guims767 depending on when you moved your app, it might not have mattered!
You can all visit https://debug.fly.dev and see which region you’re connecting to. Look for the Fly-Region header.
Indeed I moved things back to EU and it still works as my entry point is AMS.
Might just have had luck when I moved to the US.
Just an update: as far as we know network performance in Europe is good. We’re still routing around FRA. If you’re seeing network performance issues for European users please post here.
Not sure if others are seeing this, but getting warnings of:IPv6: Couldn't connect to server (207 ms) 2a09:8280:1::a92 in the last few days, for a few mins a day (15-120).
Hey @matt2 ,
Unrelated question -
What are you producing these graphs with.
They’re all so pretty, especially interested in the 2nd one (APDEX) that has fill-in type bars.
@matthewford did these clear up? Which app is this for?
Trussell trust and concordia (LRH), although on the 8th I see concordia had a short drop out on ip6.
