So, the icinga check in question was already in a bad state before the pybal restart. This check activates on any BGP session issue for the whole router (cr2-eqiad), and there are already other ongoing session issues (as is somewhat normal!). It just went from warn -> crit and then back to warn as pybal restarted. Looking at the alert history logs for this alert in:https://icinga.wikimedia.org/cgi-bin/icinga/history.cgi?host=cr2-eqiad&service=BGP+status , you can see this sequence at the top (in reverse time order):

In T307610#7918538, @Mitar wrote:

Hm, but documentation for REST API says I can use 200 requests per second? https://en.wikipedia.org/api/rest_v1/

Limit your clients to no more than 200 requests/s to this API. Each API endpoint's documentation may detail more specific usage limits.

So why I am hitting the rate limit if I am doing what is documented?

The limit you're hitting is an intentional one, from this block in our edge code:

In T251732#7892986, @bmansurov wrote:

2. Resolve the https -> http redirect issue (who should look into it?) mentioned in: