For reference, the default is 5 retries with 2 minutes delay, so we are unfortunately already taking 10 minutes for this, and this bump would make it up to 20. Really it just means we need to go take a look at the blocked PRs.

I'm fine with upping the limit, but its not actually obvious to me that that will have any effect... from looking at the logs, it looks like each retry restarts at the beginning and so it's not like doing it 5 more times will actually do anything.

From the docs, the purpose of "retryAfter" is not to get more coverage, but rather to give GitHub time to calculate if the PR is mergable

But after looking a bit more carefully at the logs with that in mind, that does actually seem to be the limiting factor here, not e.g. number of actions.

So I think that is based on number of open PRs, not necessarily ones with label (it needs to check the ones that don't have a label to see if it newly needs it) But that doesn't explain why this is a new problem (well, I guess I don't know for sure that we would for sure notice super quickly)

Let's if it improves the situation.