Description
Since March 17-18, 2026, all fresh login attempts return 429. The issue is not limited to our application — the same endpoint returns 429 from a plain curl -I with no authentication headers, from a residential IP in Italy:
curl -I https://sso.garmin.com/mobile/api/login
HTTP/1.1 429 Too Many Requests
Server: cloudflare
CF-RAY: 9dec3d344f67ea3c-FCO
FCO = Fiumicino (Rome, Italy) Cloudflare node. The block has persisted for over 4 hours with no recovery.
What works

resume() / load() with existing saved tokens → works fine
connect.garmin.com/status → returns 301 (reachable)
sso.garmin.com root → returns 404 (reachable)

What fails

Any fresh login(email, password) → 429 immediately
The block affects both garth 0.6.3 (old endpoint /sso/signin) and garth 0.7.0 (new endpoint /mobile/api/login)

Timeline

March 17: first 429 errors appeared in production logs (garth 0.6.3)
March 19 morning: updated to garth 0.7.0 — same 429, different endpoint
March 19 afternoon: confirmed 429 from plain curl on residential IP, no application involved

Question
Is this a known Cloudflare rate-limit affecting the Italian region or a broader issue? Is there a recommended probe endpoint to detect Garmin SSO availability without triggering rate-limits ourselves? We are considering using connect.garmin.com/status (returns 301) as a health check probe — would that be appropriate?
We have stopped all login attempts on our end to avoid prolonging the block. Happy to provide additional diagnostics if useful.