Summary
Received a 429 rate limit error simply by navigating to the Crow CI dashboard from a Codefloe repository. No workflow was triggered — this was a passive page load.
Steps to reproduce
- Open a Codefloe repository that uses Crow CI
- Navigate to the Crow CI dashboard
- Observe 429 response — no further action taken
Expected behaviour
Loading the CI dashboard should not trigger any rate-limited API calls, or if it does, a single passive load should be well within any reasonable threshold.
Actual behaviour
HTTP 429 Too Many Requests returned with message: “You’ve exceeded the rate limit. Please wait a few minutes before trying again.”
Environment
- Action: navigated to Crow CI dashboard (no workflow triggered)
- Source: Codefloe repository page
Agent
Safari Version 26.3 (20623.2.7.18.1)
You’re likely running into a bug in the User Agent detection/exclusion (again). Safari is tricky here. We didn’t do any changes to the rate limiting within months otherwise.
We can look into it in more detail if you provide us with a rough timestamp of when that happened. Shortly before you opened this thread here?
Yes, shortly before I opened the thread. Anyway, probably a glitch. Not doing much harm as of now.
Thanks!
I can confirm, this happens to me, too at times. And yes @codefloe it does feel like a GUI bug that disappears after retrying 10-20s later, definitely not like running into an actually rate limit.
1 Like
Thanks all for reporting!
We tracked all your reported issues down to our per-/16-subnet rate limit of 150 req/min as a distributed-bot mitigation. The CrowCI SPA fans out ~150–200 requests on a fresh dashboard load (code-split JS chunks + initial API calls), which on its own exceeds that budget, so a chunk of follow-up assets/API calls came back as 429 until the 1-minute sliding window cleared. That matches with the “disappears after retrying 10–20s later” symptom.
We have addressed this now by exempting ci.codefloe.com from the subnet rule.
1 Like
