XF Content Loss on AEM Publishers in AEM Cloud

[NageshRaja]

Hi all,

I have a weird issue which recently brought down our website's XFs in AEM on Production.

We have a bunch of 15+ XF handling headers, footers, carts and other experiences.

Most of them have been live for months if not years and were working fine.

However, on 3rd November the XF URLs started giving out 404. 

On checking the publish logs we are able to see the following - 

03/Nov/2025:15:57:45 +0000 [133066] <- 200 text/html 12ms [cm-pID-eID-wa1-aem-publish-5ghzabc579-wgkjk]
03/Nov/2025:15:57:45 +0000 [133066] -> GET /content/experience-fragments/website/en/site/experience-fragment-header/master/_jcr_content/root/freehtml.default.html HTTP/1.1 [cm-pID-eID-wa1-aem-publish-5ghzabc579-wgkjk]

03/Nov/2025:17:17:59 +0000 [204183] <- 404 text/html 14ms [cm-pID-eID-wa1-aem-publish-5ghzabc579-wxnc7]
03/Nov/2025:17:17:59 +0000 [204183] -> GET /content/experience-fragments/canadiantire/en/site/experience-fragment-header/master/_jcr_content/root/freehtml.default.html HTTP/1.1 [cm-pID-eID-wa1-aem-publish-5ghzabc579-wxnc7]

We noticed on our repository browser that the XF node itself was missing. The authors and preview servers have same number of XF while the publish had only 2/15 which no one de-activated.

Republishing the XF solved the problem but the question is how did the XF give out 404. 

We checked our author logs to ensure there was no deactivation or unpublish request triggered.

Has anyone experienced something like this?

Moreover, we want to identify the RCA and have raised adobe tickets but want to know the options on AEM Cloud for this.

Is there any way we can trace the state of the repository as the nodes dropped on publish turning from 200 to 404?

Thanks,

Nagesh

[VishalKa5]

Hi @NageshRaja ,

Your experience fragments (XFs) disappeared from AEM Publish and showed 404 errors because of a replication issue or cloud sync problem, even though nobody deleted or deactivated them. This can happen when internal AEM Cloud jobs, replication agent failures, or content package deployments accidentally remove nodes from Publish while they remain on Author and Preview.

To find out what happened:

• Check AEM Cloud audit logs and replication logs around the time the XFs went missing. These logs can show whether a system process or a deployment impacted your content.
• Adobe’s support team can help do a deeper root cause analysis, looking into backend logs and system events you can’t access directly.
• Republishing the XFs restored them, confirming it was a sync issue, not manual removal.

Best practice: Regularly review logs, set up alerts for publish-side node drops, and keep scheduled backups to prevent future issues.

Thanks,

Vishal

[NageshRaja]

Hi @VishalKa5, 

1. AEM Cloud audit logs - Which particular log file and types are you referring to here?

2. Setup alerts for publish-side node drops - Can you provide a framework for doing so? Do you use some event listener API?

Thanks,

Nagesh

[giuseppebaglio]

hi @NageshRaja, 

I would also look into whether your project has a procedure for transferring content between environments. If such a procedure exists, it's possible that the source content may not be properly updated or configured. As a result, when the content is migrated to the target environment, various issues can arise.

[NageshRaja]

Hi @giuseppebaglio, No there is no procedure for content sync between environments.

Our access to production is heavily restricted with only 2 users having access to create and install packages on production.