AEM health checks and monitoring with JMX
Adobe Experience Manager can appear healthy while quietly accumulating problems. Authoring requests may slow down, replication queues may grow, Oak indexes may consume excessive resources, and background jobs may fail without immediately producing an obvious outage. A useful monitoring strategy must therefore examine both user-facing behavior and the Java runtime beneath it.
Java Management Extensions, or JMX, provides a practical way to inspect that runtime. Through managed beans, known as MBeans, operations teams can review memory, threads, caches, sessions, repositories, and application-specific counters. Used with AEM health checks, logs, metrics, and alerts, JMX turns internal platform activity into signals that can support faster diagnosis.
The most effective approach is not to collect every available metric. It is to identify the indicators that describe normal AEM behavior, establish useful thresholds, and connect abnormal readings to an operational response. That approach works for local development, traditional servers, and containerized environments.
What JMX exposes in AEM
JMX is a standard Java monitoring interface that allows applications to publish attributes and operations. AEM and its underlying services expose information through MBeans, while the Java Virtual Machine contributes metrics for heap usage, garbage collection, thread counts, class loading, and runtime memory pools. Administrators can inspect these values with tools such as JConsole, Java Mission Control, or command-line JMX clients.
AEM-specific MBeans can provide a closer view of Sling services, Oak repositories, HTTP request activity, replication, scheduled jobs, and caches. The exact domains and attributes depend on the AEM version, installed bundles, and configuration. This variation makes documentation and baseline collection important: a metric name copied from one environment should not automatically be assumed to exist or mean the same thing in another.
JMX is especially valuable when a dashboard shows symptoms but not causes. A rise in response time may correspond with heap pressure, blocked threads, excessive sessions, or a repository operation waiting on storage. Correlating those readings with request logs and system metrics helps separate an AEM application issue from a network, database, disk, or infrastructure problem.
Establishing a useful health baseline
A health check should answer whether AEM is ready to serve its intended role, not simply whether the Java process is running. For an author instance, that may include repository access, login availability, package management, workflow execution, and author-to-publish replication. For a publish instance, it may include HTTP response behavior, dispatcher connectivity, cache status, and the availability of required content paths.
JMX metrics become meaningful when measured against a baseline gathered during normal operation. Record typical heap occupancy, garbage-collection pauses, request rates, active sessions, replication latency, job queues, and repository response times. Baselines should cover busy publishing periods and quiet periods because a value that is normal at midnight may indicate stress during a campaign launch.
Thresholds should describe sustained conditions rather than isolated spikes. For example, a short-lived increase in heap usage after a deployment may be harmless, while steadily rising old-generation occupancy over several collection cycles deserves investigation. Alerts should include duration, severity, instance role, and a link to related logs so that responders receive context instead of an unexplained red status.
Monitoring JVM and repository pressure
Memory monitoring is one of the most common JMX use cases. Heap utilization, old-generation occupancy, allocation behavior, and garbage-collection duration can reveal a developing memory problem before the process crashes. Frequent full collections, long pauses, or a heap that fails to return to its normal post-collection level may indicate oversized caches, inefficient code, large asset processing, or a leak.
Thread metrics add another layer of evidence. A high thread count is not automatically harmful, but a growing number of blocked or waiting threads can signal slow I/O, lock contention, or an overloaded downstream service. Thread dumps captured during the event can show whether requests are waiting on repository access, HTTP calls, file operations, or application synchronization.
Oak and Sling require operational attention as well. Repository checks should include available disk space, segment or document-store behavior, query performance, index health, and the rate of repository changes. AEM administrators should combine JMX observations with Oak run logs, query explanations, and storage monitoring. JMX can identify pressure; it may not explain every repository-specific cause by itself.
| Area | Useful signals | Warning pattern | First response |
|---|---|---|---|
| JVM memory | Heap pools, old-generation use, collection pauses | Rising post-GC usage or long pauses | Capture diagnostics and review allocation sources |
| Threads | Live, blocked, and waiting threads | Sustained growth or request-thread exhaustion | Take thread dumps and inspect slow dependencies |
| Requests | Active requests, rates, and response timing | Increased latency with normal traffic | Correlate with logs, repository calls, and network metrics |
| Replication | Queue depth, errors, and delivery age | Stale or continuously growing queues | Check agents, permissions, transport, and publish health |
| Jobs and workflows | Queue size, failed jobs, execution duration | Backlog growth or repeated failures | Inspect workflow steps and service dependencies |
| Repository | Query timing, index behavior, storage capacity | Slow queries, disk pressure, or index errors | Review indexes, storage, and recent content changes |
Connecting AEM to external services
AEM installations often depend on search platforms, identity providers, commerce systems, asset processors, analytics endpoints, and custom APIs. A JMX view of AEM can show that request threads or jobs are waiting, but external-service metrics and application logs are needed to identify the failing boundary. Tracking dependency latency, timeout counts, and error rates alongside AEM MBeans creates a clearer service map.
Integration code should expose meaningful counters where possible. A custom OSGi service can publish calls attempted, successful responses, failures by category, retry counts, and current in-flight requests through its own MBean. That is more actionable than a single generic “integration failed” log message. Teams working through third-party APIs should also define timeout and retry behavior so that a remote outage does not consume every AEM request thread.
JMX endpoints require careful security controls. Remote access should use authentication, encryption, network restrictions, and a controlled management port. Exposing an unauthenticated JMX connector to the public internet can provide dangerous access to runtime information or management operations. In production, many teams collect JMX data through a secured agent or exporter and send selected metrics to a central monitoring platform rather than granting broad direct access.
Making health checks work in containers
Containerized AEM development and deployment add another layer to monitoring. A container restart may hide a memory problem, while a replacement instance can erase local evidence needed for diagnosis. Container health probes should therefore check meaningful application readiness, such as a successful authenticated request or a required service state, rather than treating an open Java port as proof of health.
Environment consistency also affects interpretation. Teams using Docker development environments should keep JVM options, AEM configuration, monitoring agents, and health-check behavior close to production where practical. Development containers can use lightweight dashboards and local JMX inspection, but staging should test alert thresholds, startup behavior, persistence, and failure recovery under realistic load.
Resource limits must be visible in both the container platform and the JVM. A heap percentage that seems acceptable may still approach a container memory limit once native memory, thread stacks, and libraries are included. Monitor container CPU, memory, restarts, file descriptors, and network activity beside JMX readings. This prevents a Java-only diagnosis when the actual problem is throttling or an imposed memory ceiling.
Linking content activity to platform signals
Content operations can produce technical symptoms that look like infrastructure failures. Bulk imports, asset processing, tag changes, workflow launches, and large package installations may increase repository writes, queue depth, CPU use, and temporary storage consumption. Monitoring should preserve enough context to connect these changes with deployment records and editorial activity.
AEM tagging and content structure also influence query behavior and authoring workflows. Poorly governed vocabularies can create inconsistent metadata, while excessive or redundant taxonomy values may increase maintenance work and complicate search. Teams reviewing tagging taxonomy should consider content governance a monitoring concern as well as an editorial concern: unusual tag growth, failed indexing, and slow metadata queries can all become operational signals.
Dashboards should separate author and publish roles. An author dashboard may emphasize workflows, imports, repository writes, active sessions, and replication queues. A publish dashboard should prioritize request latency, error rates, cache behavior, JVM pressure, and availability from the visitor’s network path. Shared metrics such as disk capacity and bundle failures remain important, but role-specific views reduce noise during incidents.
Turning observations into operating practice
Monitoring succeeds when people know what to do after an alert fires. Each important metric should have an owner, a severity, a runbook, and a method for collecting evidence without worsening the incident. Useful operating practices include:
- Protect JMX with authentication, encryption, access controls, and a restricted management network.
- Create separate baselines and alert thresholds for author, publish, dispatcher, and development environments.
- Correlate MBean values with logs, request traces, repository checks, container statistics, and deployment events.
- Capture thread dumps, heap data, queue details, and recent configuration changes during sustained incidents.
- Review alert quality regularly so transient spikes do not train responders to ignore important warnings.
A periodic health review should examine trends rather than isolated dashboard snapshots. Look for gradually increasing heap occupancy, longer replication age, repeated workflow failures, expanding query times, and changes after bundle or content deployments. Trend analysis often identifies capacity problems early enough to address them during planned maintenance.
JMX is most effective as one layer in an observability system. It supplies deep Java and AEM runtime detail, while logs explain events, traces connect dependencies, infrastructure metrics show resource limits, and synthetic checks confirm the experience from outside the instance. Together, these signals provide stronger evidence than any single health endpoint.
Start by inventorying the MBeans and health indicators available in each AEM role, then document normal operating ranges during representative traffic. Secure the collection path, connect the selected metrics to dashboards and alerts, and test the response with controlled failures such as a paused replication agent or unavailable downstream API. A measured implementation will make AEM behavior easier to understand, incidents faster to investigate, and platform capacity decisions more defensible.