No idea if that's what's going on, but routing protocols are one of a few effectively global control planes that can go wrong very quickly like this.
Traceroute from "the internet" back to that IP reaches AS14593 just fine, and my endpoint doesn't get beyond the first hop of the local starlink router.
Whatever it is, it doesn't look like a peering problem
One of the promises of starlink was it would stay in space as long as possible before being downlinked, giving far lower latency, alas that hasn't happened yet, and traffic will run thousands of miles in the wrong direction before being downlinked. For example from one location to another I have 360ms via Starlink but just 200ms rtt via local provision (5g p2p wireless then optical). On another it used to downlink in Lagos, but now it downlinks in Nairobi, meaning traffic to Lagos routes Nairobi -> Marseille -> Lagos, taking far longer than it used to. A shame really.
Whoever is doing immediate global deployments and/or any prod deployments without verified testing is just wrong as a corporate culture.
But hey, if you haven’t caused an incident yet, that just means you’re still in onboarding. Those SLA downtime budgets are there to be spent.
It says it didn’t, and it says the “which way is down” thing hasn’t converged. Occasionally, the signal to noise ratio light in the app goes gray which means < 3.
It also rebooted itself.
Before the first reboot, 30% of pings went through. It’s almost like the azimuth or some other timely but cached data was corrupted.