Understanding AEM cache expiration and Dispatcher TTLs

AEM caching can make a published site feel immediate, but stale content quickly becomes visible when time-to-live settings are unclear. The Dispatcher sits between visitors and AEM Publish, serving cached files until they expire or an invalidation event removes them. Configuring that relationship well requires more than choosing a number of seconds.

For Australian organisations, the stakes can be particularly practical. A campaign may need to update across Sydney, Melbourne, Brisbane and Perth during different business hours, while users on variable NBN or mobile connections expect fast pages. A clear expiry policy helps teams balance performance, publishing speed and content accuracy across a large geographic market.

Why cache expiration matters in AEM

A Dispatcher cache stores rendered responses as files on the web server. When a request arrives, Dispatcher can return the cached file without asking AEM Publish to render the page again. This reduces application load and improves response times, especially for high-traffic landing pages, product listings and media-heavy experiences.

The difficulty is that a cached response has a useful life. A page containing a promotion, event date or stock message cannot remain available indefinitely. If the lifetime is too long, visitors may see obsolete information. If it is too short, requests pass through to AEM so frequently that the performance benefit is reduced.

The right value depends on content behaviour. A corporate “About us” page may safely live for hours, while a news page or pricing component may need a much shorter lifetime. CIRCUIT’s conference archive provides useful context for the AEM engineering community, where these decisions often sit between application architecture, operations and editorial workflows.

How Dispatcher TTL processing works

Dispatcher TTL support is enabled in the cache configuration with /enableTTL "1". When this is active, Dispatcher evaluates response headers such as Cache-Control: max-age and Expires. The calculated expiry is stored with the cached file, allowing Dispatcher to determine whether the object is still fresh.

A crucial operational detail is that expiry is generally checked when the resource is requested. Dispatcher does not behave like a separate scheduler that wakes up and deletes every expired file at the exact second its lifetime ends. The next request discovers that the cached item is stale, after which Dispatcher can fetch a current response from Publish.

This means a page can remain physically present in the cache directory after its TTL has elapsed, without being served as fresh content. It also means the first request after expiry may experience a cache miss. For high-value pages, teams should consider request coalescing, warm-up processes or CDN features that reduce a sudden origin surge.

TTL headers can be produced by AEM, Apache configuration or an upstream delivery layer. Choose one authoritative policy wherever possible. If AEM sends max-age=300 and a CDN applies a different rule, the effective behaviour should be documented rather than left to assumptions. The CIRCUIT agenda reflects the range of integration and architecture concerns that can influence this design.

Configuring TTLs in the Dispatcher

A simplified Dispatcher cache configuration might look like this:

/cache {
    /docroot "/var/www/html"
    /enableTTL "1"

    /rules {
        /0000 {
            /glob "*"
            /type "allow"
        }
    }
}

The TTL itself is usually supplied through the response headers from AEM Publish. For example, an Apache or AEM response might include:

Cache-Control: max-age=600, public

This instructs a cache to treat the response as fresh for 600 seconds. In a real implementation, configure headers selectively rather than assigning the same value to every path. Static assets with fingerprinted filenames can often have a long lifetime, whereas HTML pages and JSON endpoints need shorter periods.

Review /rules, /invalidate, /ignoreUrlParams and /statfileslevel alongside TTL. A request that contains query parameters may create unexpected cache variants if those parameters are included in the cache key. Conversely, ignoring a parameter that changes the response can cause incorrect content to be reused. Cache rules must also exclude authenticated, personalised or form-submission responses.

Do not place private or user-specific material in a public cache. Cookies, authorisation headers and session-dependent responses require careful handling. AEM user permissions and Dispatcher filtering should be designed together; the practical guidance in access control practices is relevant when deciding which requests can safely be cached.

Coordinating TTL with invalidation

TTL and invalidation solve related but different problems. TTL provides a time-based freshness limit. Invalidation removes or marks cached files when content is activated, often through Dispatcher flush agents or a CDN purge process. A page with a 30-minute TTL may still need immediate invalidation when an emergency notice is published.

The /statfileslevel setting influences how Dispatcher uses .stat files to identify changed content. A low level may invalidate broad sections of the cache, while a higher level can make invalidation more targeted. The correct setting depends on the site structure, activation patterns and the cost of rebuilding pages.

Australian publishing calendars deserve attention here. A retailer preparing an EOFY campaign may activate thousands of pages in a short window, while a government or health service may need urgent updates during a Queensland weather event. Schedule large activations away from peak traffic where possible, and test whether flush traffic reaches both local and interstate delivery layers.

Remember that a CDN may continue serving content after Dispatcher has refreshed it. Fastly, CloudFront or another edge network can have its own TTL, stale-while-revalidate rule and purge API. The complete path—from browser to edge cache, web server, Dispatcher and AEM Publish—must be included in the freshness model.

Testing cache behaviour safely

Testing should begin with response headers. Use browser developer tools or command-line requests to inspect Age, Cache-Control, Expires, ETag, Last-Modified and any vendor-specific cache status header. Compare the first request with repeated requests, then test again after the configured lifetime has passed.

Test both successful and bypass conditions. Check anonymous visitors, logged-in users, requests with cookies, query strings, language selectors and trailing-slash variants. Confirm that author mode is never exposed through a public cache path. A response that appears correct in an authoring browser can still be unsafe or misleading for an anonymous visitor.

Measure the first request after expiry. If every expired page causes a costly render, a popular Australian campaign page could create an avoidable load spike at lunchtime in Sydney or during the evening commute in Perth. Monitor Publish CPU, request queues, Dispatcher hit ratio and origin response time while running controlled load tests.

Include daylight-saving behaviour in operational procedures. Sydney and Melbourne move between AEST and AEDT, while Brisbane remains on standard time, so a deployment described as “midnight local time” can be interpreted differently by distributed teams. Use explicit timestamps and time zones in cache purge runbooks.

Choosing practical lifetime values

There is no universal Dispatcher TTL. A useful policy classifies resources by how quickly their meaning can change and how expensive they are to regenerate. It should also explain who can trigger an invalidation and how long a stale response is acceptable.

Resource type	Typical starting TTL	Invalidation approach	Main consideration
Fingerprinted CSS, JavaScript and images	7–30 days	New filename on release	Safe when filenames change for every build
Stable content pages	30–120 minutes	Activation flush	Good balance for low-change pages
Campaign and landing pages	5–30 minutes	Immediate purge for launches	Coordinate with marketing schedules
News, alerts and service notices	30 seconds–5 minutes	Flush on publication	Freshness is more important than hit ratio
Personalised or authenticated responses	Do not cache publicly	Session or private cache	Prevent data leakage

Treat these figures as starting points, not promises. Track cache hit ratio, origin traffic and publishing latency after each change. A 60-second TTL may be excessive for a page that changes twice a day, while a 24-hour TTL is unsuitable for live service information.

Teams can document the policy alongside Dispatcher configuration and deployment code. For broader engineering and community material, technical resources can sit alongside internal runbooks, provided the production rules remain specific to the organisation’s AEM version, CDN and release process.

Apply a measured TTL strategy to your AEM environments: inspect the headers, test expiry and invalidation together, and record the policy for each content class. With that discipline, Dispatcher can deliver fast experiences without turning yesterday’s content into today’s problem.