[collectedparts]

It doesn't seem to include any backoff, so any browser tab left open on that screen will keep tightlooping on it. Almost certainly exacerbating the problem.

What should my mental model be for "where" the code that causes those repetitive API requests is coming from? JS logic deployed to a CDN somewhere?

If so, seems it may be an interesting question of whether or not it's possible to ship a hotfix (add exponential backoff) to JS asset in time to be helpful in fighting an outage like this.

[collectedparts]

(self-reply) looks the API call is coming from a script in "main.ed70037a.js" which is loaded from: https://abs.twimg.com/responsive-web/client-web/main.ed70037...

From nslookup, abs.twimg.com has canonical name twimg.twitter.map.fastly.net.

Honestly pretty shocked that something at their scale could be depending on Fastly for core assets.

[cowsandmilk]

> Honestly pretty shocked that something at their scale could be depending on Fastly for core assets.

Why would that be surprising? Fastly has many customers of similar scale. Amazon.com has fastly as one of the options to serve as their CDN (as was publicized when a fastly outage took down amazon briefly last year).