Recurring account-wide HTTP 429 across all active shares — share count ruled out, 5 other fixes tried, none resolved it
Setup:
- 1 environment, normally 6 active public reserved shares (fixed subdomain names via
zrok share public --subordinate -n public:<name>), each proxying a lightweight local HTTP service - Free tier, account verified with a card (no interstitial)
- Usage per share: one small JSON poll roughly every 30 seconds — well under any published rate limit (2000 req/300s per IP, 7500 req/300s per share)
- zrok v2.0.4 on Windows
Symptom: Every active share returns HTTP 429 simultaneously (never staggered — always all of them in the same short window, confirmed via each share's own access log showing zero gap or error right up until the moment the browser-side client starts getting 429 responses — the local tunnel process itself shows nothing wrong, meaning the rejection happens entirely at zrok's edge). This has recurred repeatedly across multiple days, sometimes several times in one day, gaps between incidents ranging from under a minute to several hours. Each incident usually clears on its own after 15-33 minutes provided nothing touches the account during that window (we added client-side logic to detect the pattern and go fully silent — no share create/delete calls at all — until it clears), but today one incident recurred less than 60 seconds after appearing to clear.
What we've tried, each a genuine attempt at a fix, none of which changed the pattern:
- Staggered our shares' startup (45s apart instead of near-simultaneous) — reduced simultaneous first-boot failures, but the recurring throttle still happens hours into steady operation, unrelated to startup timing
- Deleted 17 old orphaned/unreserved shares left over from earlier testing — no measurable change
- Removed a 7th, unrelated share entirely — no measurable change
- Verified the account with a card to rule out anti-abuse throttling on unverified accounts — no measurable change
- Found and killed a duplicate local recovery-automation process that had (unknown to us) been running two copies simultaneously, each independently capable of deleting/recreating shares on failure — a real bug, but the throttle recurred again ~18 minutes after confirming only one process remained and the account had zero duplicate/orphaned shares
- Reduced active shares from 6 to 3 and ran them in isolation for a controlled test, with no automation/recovery process running at all — all 3 shares still hit
HTTP 429simultaneously, at essentially the same elapsed time into the run as our 6-share setups typically do
What the zrok web console shows: normal-looking small activity graphs, no warnings, no near-limit indicators, account status "Free - Verified."
Question: With share count, orphaned resources, verification status, and our own automation all ruled out as the cause, is there a known rate limit or anti-abuse heuristic — not covered in the published per-IP/per-share request limits — that could produce a synchronized 429 across every active share on an account, independent of how many shares are active? Something tied to account age/history, a global per-account request ceiling regardless of share count, or a time-based pattern we're not seeing? Any pointers on what to check next, or logs/details that would help you diagnose it, would be appreciated.
Happy to share exact timestamps, share tokens, or full zrok2 overview output if useful.