I think we have no realistic way forward here. See T13201 for related things which are moving forward.

I don't currently plan to make "Disable User" any more granular than it is. If you have a use case where you want multiple administrator levels and to allow administrators at a certain level to act downward but not upward, you might be able to do something like have an enforcer-bot account which users can instruct to disable one another. The enforcer-bot itself could act via the API.

In T9041#240610, @epriestley wrote:

"Disable User", specifically, is now granular.

Use cases we've seen FWIW:

• This feature was originally added in D1378.
• This feature was accidentally broken by D11169.
• In D19661, I removed the nonfunctional remnants of D1378.

I wrote a patch for this, for both new log prototype and old log viewer here some screenshots for the view. If it is look OK, I will submit it.

This is now live.

Deploying the changes to web now.

I've issued all instances a 24-hour service credit for the disruption. This should be reflected on your next invoice.

Here's the request rate leading up to the rate limiting:

D19653 (above) changes the per-"Host" rate limit to require "X-Forwarded-For" be present in the request. This should exempt ELB requests from these limits.

... in production today as a next step.

This should have the pleasant side effect of letting us drop the goofy hard-coded internal rate limiting IP list.

There are four rate limits, and I don't currently have enough information to figure out which one triggered. The rate limits are:

The remaining work on the audit constants is:

See also PHI862 for a request for arc amend --force.