Warming one AEM URL does not warm every Dispatcher pod

An AEM Cloud team saw dynamic pricing pages load in 3–4 seconds on a miss. One public-domain warmer pass made some subsequent requests fast, but another Dispatcher pod could still miss. Running the warmer twice helped in their environment. That observation does not prove that two passes cover every pod or CDN location.

Identify which cache answered

Adobe's delivery flow places CDN, Dispatcher and publish in sequence. A fast response may be a CDN hit and say nothing about a second Dispatcher pod. Measure request timing with the available CDN and Dispatcher logs, response headers and a controlled set of URLs. Separate first request, repeated request, post-deployment request and requests from relevant regions. Avoid adding random query parameters: they can create new CDN cache keys rather than test the intended page.

Make pricing freshness explicit

Dynamic pricing has a freshness requirement as well as a latency requirement. Record where the price is fetched, whether the response is safe to cache, and the maximum acceptable age. Adobe's caching guide describes how response headers control CDN caching and how Dispatcher caching differs. A warmer cannot fix a cache policy that serves stale prices or refuses to cache the response.

Test the operating plan

Choose a representative URL set, observe it through deployment and expiration, and define a latency budget for misses. If a scheduler runs inside AEM, verify its execution location and load effect in the target environment. If it runs externally, treat requests as ordinary client traffic and test the resulting distribution. Neither choice should be assumed to target each pod or POP.

Adovo’s view

Cache warming is a measurement problem before it is a scheduling problem. A page that is fast once may only prove that one layer was warm. Set the freshness contract first, then test the path a customer actually takes.