Skip to main content
← BlogLeer este artículo en español →
AEMAEMaaCSAuditTroubleshooting

Who Deleted That Page in AEM as a Cloud Service?

AEM tells you who created, modified or published a page — but when someone deletes it, silence. Here is how I solved the mystery with /var/audit and the Developer Console.

7 min read

Do you know who deleted that page in AEM as a Cloud Service? I had to solve this mystery at work, and I was surprised by how unintuitive it is to find out. In this article I explain the problem, the reasoning I followed and the step-by-step solution, so that the next time someone asks you "who deleted this page?" you have the answer in five minutes.

The problem: AEM stays silent about deletions

AEM Sites is fairly transparent about the lifecycle of a page... up to a point. From the Sites console you can easily see:

  • Who created the page (jcr:createdBy).
  • Who last modified it (cq:lastModifiedBy).
  • Who published or unpublished it (cq:lastReplicatedBy and the replication properties).

But when someone deletes it... silence. The page disappears from the console and with it, apparently, any trace of who executed the action.

It is true that not everything is lost at the content level: you can restore the page or check its previous versions. With one important caveat, though:

But even when you can restore it, nowhere in the interface does the person responsible for the deletion appear. And sometimes that is exactly the question you are being asked: not "recover the page for me", but "who deleted it and when?".

The reasoning: if it can be restored, it has to live somewhere

This is where the detective part comes in. My reasoning was simple: if AEM is able to offer you the restoration of a deleted page, the archived pages — and the record of the action — have to be stored somewhere in the JCR repository. The interface does not show it, but the data has to exist.

The question was: where to look, given that in AEM as a Cloud Service you do not have CRX/DE in production?

The tool: Developer Console from Cloud Manager

In AEMaaCS you cannot connect to the production repository the way you did in the on-premise versions. But Adobe provides an alternative: the Developer Console, accessible from Cloud Manager.

The steps:

  1. Log in to Cloud Manager with your user for the environment.
  2. Locate the environment you are interested in — in my case, the author instance of PROD, which is where authoring actions such as deletions happen.
  3. Open the Developer Console of that environment.
  4. From there you can inspect the instance's repository and navigate its paths.

The prize: /var/audit

Navigating the repository I reached the key path: /var/audit. That is where AEM stores the audit log of actions performed on content.

The structure is quite recognizable: under /var/audit you will find a tree replicating the paths of your pages, and hanging from each path, nodes identified by IDs representing each action performed on it:

/var/audit
└── com.day.cq.wcm.core.page
    └── content
        └── my-site
            └── en
                └── my-page
                    ├── 1f3a9c72-...   ← one action
                    ├── 8b21d5e0-...   ← another action
                    └── ...

And in each of those nodes there is everything you need:

  • The type of action executed (creation, modification, deletion...).
  • The affected path.
  • And, most importantly: the user who performed the action ✅

With that, mystery solved: action type PageDeleted, path of the page, timestamp of the event and the responsible user. Exactly the answer nobody could find in the interface.

Details worth knowing

A few nuances I learned along the way that can save you time:

  • The audit log has its own scope per event type. Under /var/audit you will see different branches depending on the component generating the event (WCM pages, DAM, replication...). For page deletions, the WCM branch is the one that matters.
  • It is not eternal. Audit records are repository content and are subject to the maintenance and purge tasks configured on the instance. If the deletion happened long ago, the record may no longer exist — the sooner you investigate, the better.
  • It complements, not replaces, other avenues. For replication actions you have the replication logs, and in AEMaaCS you can also rely on the environment logs via Cloud Manager. But to answer "who deleted this page?", /var/audit is the direct route.

Conclusion

What started as a mystery — a vanished page and no one responsible in sight — ended up being a lesson about how AEM works internally: the interface does not always show everything the repository knows. If AEM can restore a deleted page, it is because it keeps the trace somewhere; you just need to know that this place is /var/audit and that the Developer Console in Cloud Manager is your gateway in AEMaaCS.

I hope you find it useful or, at least, that it strikes you as curious as it did my colleague and me when we discovered it 🤪