Maintenance in AEM 6 with CRX3 TarMK

AEM maintenance is a key to a successful and healthy system. Here are some of the most important things to remember when operating an AEM system to keep it running like the first day.

Maintenance in AEM (Adobe Experience Manager) or formerly CQ (Communique) is a large but important topic to consider when setting up a new system. It is, in fact, the key to a successful and healthy system which can keep its stable status for a long time. Some specific details need to be considered when thinking about maintenance.

Audits logs

When there is an unexpected change to content or the system the audit logs are the key for analysing what caused the issue. Audit logs need to be handled with care since they can bloat the repository quite quickly. Nevertheless, in many cases you need to keep a certain amount of them due to legal requirements.

The audit logs are disabled per default with Oak. If you do require them to be configured simply create a logger in http://localhost:4502/system/console/slinglog. Bear in mind that the regular audit log is only accessible with high level permissions and accessible in /var/audit via the /crx/de. Documentation from CQ 5.6 still partially applies and is documented here by Adobe: the Audit Records.

Furthermore, audit page event nodes are disabled per default on publish they also don't need to be purged on publish. The purge itself is accessible via the maintenance dashboard in AEM 6.1.


Similar to audit logs, versions need to be purged every now and then. For versions this can be done using an OSGi configuration. To keep data, the amount and timeframe need to be verified carefully during the discovery phase of a project. Versioning as a whole can be disabled on publish to reduce the node count drastically.

  1. A proper OSGi configuration should be in place.

2. Simply go to http://ip:port/etc/versioning/purge.html where you can initiate a purge.


Workflows can be a burden on the system as well, especially if there are many failed or completed workflows present. Ensure that a proper configuration is in place for completed ones to be purged. Keep in mind, a manual purging makes sense in some cases when on a test or dev system. Below you can find some details and example configurations for the versioning and workflows.

  1. A proper OSGi configuration should be in place.

Simply leverage the workflow remover from ACS commons


Compaction is the "new" tar optimisation (in the end it still optimises tar files). I already covered this topic in a previous article but I will revisit the topic again to clear up some possible doubts.

  1. Use the Oak run version matching the Oak version you have deployed.
  2. Offline compaction weekly or when needed (this applies to all environments).
  3. Online compaction daily for smaller repositories, test instances, dev instances (when the system is under heavy load this can be an additional burden - at this time, it is recommended to be turned off for production systems).
  4. Stay on the ball with Oak hotfixes; they tend to contain many patches for Oak and also the compaction!

In the meantime Adobe has described the online compaction as a whole quite well and can be found in their knowledge book\\_6\\_TarMK\\_Online\\_Compaction.html. Since AEM has this new shiny dashboard it can also be triggered via the maintenance dashboard.

Closing round

Maintenance in AEM is very important. Without maintenance the instance will start to run the AEM badly, sooner or later. It will be more work-intensive to get the instance back up and running than keeping it clean and maintained properly from the start. Look at it this way, it is similar to a car. If you keep it maintained you will have a better experience with it over its entire life-cycle.

On the other hand, if you do not maintain it, you will likely have costly problems in a few months or years. It can end up in such an irreparable state that the costs of repairing it outweigh the costs of maintenance since the beginning.