Uptime Robot badges randomly say "invalid"

[tdulcet]

Are you experiencing an issue with...

shields.io

🐞 Description

Some of the Uptime Robot badges will randomly and erroneously say "invalid" instead of showing the uptime percentage as expected:

The ones that say invalid are not consistent, as refreshing the page after a while just causes different ones to say invalid.

🔗 Link to the badge

Here is the link for the README that the above screenshot was taken of: https://github.com/timvisee/send-instances/blob/master/README.md#instances

💡 Possible Solution

No response

[chris48s]

Hello. I've had a look at one of the ones that was failing and the reason they're failing is because of a 429 Rate limit exceeded, retry in 20 seconds.
With uptime robot, the API key used is user-supplied so I guess you are exceeding the rate limit for your plan.

[chris48s]

Just to help you look at this, if you run want to check the rate limits for one of your keys (lets take m794230712-50b203eb6aba33e7ed9f35a4 as an example), you can run:

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -d 'api_key=m794230712-50b203eb6aba33e7ed9f35a4&format=json&logs=1' "https://api.uptimerobot.com/v2/getMonitors" --include

and look at the x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset headers

[tdulcet]

@chris48s - Thanks for the information. I can confirm that the rate limit is being exceeded:

x-ratelimit-limit: 10
x-ratelimit-remaining: 9
x-ratelimit-reset: 1683707896

However, this "invalid" message implies that the API key is invalid, which is incorrect. It should say something like "rate" or "limit" instead to make this clearer or maybe not even load at all like the Dynamic badges do when the server for url parameter is down.

Ideally, Shields.io should be caching these Uptime Robot API responses and then just returning those cached values whenever this rate limit is reached. Another solution would be for the Shields.io server to just wait out the 20 seconds and then retry the API request until it succeeds. Most browser response timeouts are much more than 20 seconds, so while this obviously would not be ideal for the user, it should at least work. I just loaded our README again and now 16 of the 17 Uptime Robot badges say "invalid", so they are completely unusable in their current state. Please consider reopening this issue.

[chris48s]

I think its reasonable for us to add a custom error for the 429 response to make this clearer: #9159

Shields is basically stateless and we don't cache any upstream API responses. We do cache the badges themselves downstream though. Uptime robot badges are cached for 2 minutes by default, but you can explicitly ask us to cache them for longer using the cacheSeconds query param.

We've had these uptime robot badges for a really long time and this is the first time I've seen anyone report this issue. I've had a look at the docs on the wayback machine and this limit has been in place for some time (it is not something they've just added or reduced recently). It seems unlikely that everyone who uses these badge has a paid account with a higher rate limit. I can't really check this myself, but I can see each of your badges uses a different API key. Are they all attached to different accounts, or is it the case that they are all attached to the same free account (and share that same low rate limit across all the keys)? If its the second one, I'd guess we've not seen this before because what we're doing works fine for free plan users who just want a badge for one site, but it falls down if you try to use loads of them on a free plan.

The most common place where shields badges are viewed is on GitHub. All images on GitHub are served via an instance of camo (GitHub's image proxy). Camo will only wait 4 seconds for a response from an upstream (like shields.io) before returning an error, so any badge that takes more than 4 seconds to return a response won't display for most users.

[tdulcet]

Thanks for creating that PR.

Caching the badges downstream would be good as there is no need to reload them more than once per hour or so. However, we of course would not want to cache any badges in that "invalid" state.

Hmm, I just looked at the Wayback Machine as well and the first reference I see to this rate limit was on October 24, 2021, around 1.5 years ago. This is the first time I have personally used these Uptime Robot badges, so I would never have noticed this before. Anyway, yes, most users are probably only using a single one of these badges, so with this 10 requests/minute API limit, they can have up to 10 views per minute, which must be enough for those users. However, our README currently needs 17 badges (likely more in the future), which means only a random 10 will work, as can be seen from my above screenshot. If we get more than 1 view per minute, less than 10 will work.

To answer your question, the Uptime Robot badges require using the "monitor specific API keys" (see the documentation), so yes, each of those keys is for a different monitor with the same free account.

Uptime Robot supports having up to 50 monitors for free, so users should be able to have 50 badges and they should all work, regardless of how popular their page is and how many views it might get. It seems this might be a fundamental problem with how the Shields.io service is currently designed. I do not see how you could comply with this strict API limit without caching their API responses for at least a short amount of time. Uptime Robot only supports checking the monitors at most once every 5 minutes with their free plan, so making any API requests more often than that is just redundant anyway. In addition, the larger the number of days for the ratio, the less frequently the response will change.