AEM Cloud Adaptive Rate Limiter: Understanding “Server Load Exhausted” and Prediction

Hi ​@Lively_Elixir8a29 

The main thing to read from that line is that you are being load-shed, not concurrency-limited.

inflight is only 68/200, so you are nowhere near the concurrent request cap. The rejection is happening because server load is basically maxed (749009 of 750000), and your request's predicted cost (35381) would push it over the ceiling.

In simple terms: it is not too many requests, it is a few expensive ones eating most of the resource budget. That 68/200 but load-maxed pattern almost always points to heavyweight operations rather than traffic volume.

Two places I would start. First, the rejected URL is often the victim, not the cause, so check what else was in-flight at that timestamp burning the load. Second, look for expensive queries (unindexed QueryBuilder or JCR-SQL2, or traversals), which are the usual reason load spikes while concurrency stays low.

One note: this filter is Adobe-managed and the thresholds are not customer-configurable, so the goal is reducing cost per request, not raising the limit. If you are still seeing sustained rejections under legitimate load after optimizing, raise it with Adobe support with the timestamps and URLs.

Hi ​@Lively_Elixir8a29 ,
This log indicates that the request was rejected by AEM Publish's JVM Adaptive Rate Limiter because of predicted server load—not because the in-flight request limit was reached.

In this example, the current server-load value is 749009/750000, while the in-flight count is 68/200. The limiter's prediction value indicates that the request's predicted load would exceed the available headroom. So a below-limit in-flight count does not rule out a rejection: the server-load check is a separate condition.

The log explains why this request was rejected, but not what caused the load. To investigate, correlate the timestamp and rejected path with publish access/error logs and CDN/Dispatcher logs; check whether those requests are cache HITs or are reaching the origin as MISS/PASS; and look for slow or expensive endpoints, bursts of traffic, recent deployments or cache changes, and client retry patterns. Requests reaching AEM more often than necessary can increase origin load; review CDN and Dispatcher caching for eligible content.

For clients making programmatic requests, handle HTTP 429 responses with a delay and exponential backoff rather than immediate repeated retries. If the issue continues under normal traffic, share the UTC timestamps, affected paths, sample log lines, and related access/cache evidence with Adobe Support.

the sample supports the interpretation of the rejection, but it cannot prove whether the underlying load came from cache bypass, slow application work, a traffic burst, or another cause. Adobe's guidance also notes that AEM's handling depends on request load and that the right response is to investigate the workload and caching—not to infer a universal requests-per-second threshold from this line.