How can i get my IP Address removed from your blocklist…??
Have you recently put more robust checking on your inbound connections??
We are being blocked repeatedly w/429 Too Many Requests errors.
As a result we are going to setup a local APTLY repo and sync that w/mirror updates on a regular basis. However, right now, we are even being blocked when we try to do an aptly mirror update to your “influxdata-stable https://repos.influxdata.com/debian stable main”.
Are you a InfluxData customer or an open source v2 user? If a customer you can file a ticket with our team. Also can you provide more details on what were you trying to do where and what was the exact error message as that will help triage the issue better.
Just ran into the same thing.
OP is a bit vague, but assuming it’s the same issue, then we ran into this with influxdbdata repo when attempting to install telegraf:
Errors during downloading metadata for repository ‘influxdata’:
- Status code: 429 for https://repos.influxdata.com/stable/aarch64/main/repodata/repomd.xml
Error: Failed to download metadata for repo ‘influxdata’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
This literally happened after 3 install, three, not thirty. I am hoping someone made a mistake, otherwise this is pretty bad news for anyone with more than 3 servers behind the same NAT.
I’ve started to the see this as well.
Since 2026-02-05, the InfluxData package repository (https://repos.influxdata.com) seems to have implemented some very sensitive rate-limiting.
If you access the repos too often, the webserver will return “HTTP 429 too many requests”.
After waiting for some minutes, the rate limit is lifted and access is possible again.
The limit seems to be something around far less than 10 requests/s. Trying to mirror the repo via `dnf reposync –newest-only` for a single architecture barely works, add a second architecture and you most likely run into the rate limit.
This make it very hard to maintain an internal mirror, which (ironically) would reduce the load on https://repos.influxdata.com
I guess the original poster also ran into this issue when setting up an internal mirror for APT to overcome the limit.
Long story short, it would be great if the rate limiting on the InfluxData package repository could be checked.
A slightly less sensitive rate limit would be highly appreciated for mirroring use-cases.
Cross posted in the github repo: Influxdata repo rate limiting too strict · Issue #18312 · influxdata/telegraf · GitHub
Frankly I just need to know if this is intended or not.
Hi @tonyswu @stdietrich @DRock777 yes, this was a recent change and thanks for reporting your issues. Adjustment has been made to the rate limit, it should be better now, let us know if you’re still seeing errors. Also if you can share any more information such as what might be your typical request volume it will help us greatly. Thanks!
Thanks very much, good to know if wasn’t intended.
For us, our use case is usually pretty small. We run telegraf primarily on our AWS ECS clusters, and while we do allow our clusters to scale up it typically doesn’t scale more than 2 at a time. We ran into this, however, during AMI refresh when we were trying to refresh all ndoes within a cluster (this was a small cluster of 6 nodes) and it failed half way. Our biggest cluster is 25 nodes, so I’d say that’s probably our biggest potential spike of traffic which doesn’t happen often.
Thanks this helps Tony!
Thanks for taking care of this!
We mirror repos.influxdata.com once per day from a single machine, which downloads all the metadata and packages.
If the package is already locally available, it doesn’t download them again.
Also, it’s only a partial mirror for selected architectures (x86, aarch64, ppc64le).
Our machines are configured to use the mirror and never access repos.influxdata.com directly.
So this machine needs to be able to download all metadata related files + new packages for multiple architectures.
Right now, the rate limit seems to be fine for our mirroring use-case.
