Preserve X-Correlation-Id in AEMaaCS error responses (404/500)
In Adobe Experience Manager as a Cloud Service, you use the X-Correlation-Id header to trace requests across AEM, Dispatcher, and CDN layers. While this header appears in successful (200 OK) responses, it’s missing in error responses like 404 Not Found or 500 Internal Server Error, even though AEM logs confirm it was set. By default, CDN replaces AEM error responses with synthetic pages, which strips custom headers. This breaks monitoring and debugging workflows, making it difficult to correlate client-side failures with backend logs.
To fix this, add the x-aem-error-pass: true header to error responses. This tells the CDN to forward the original AEM response instead of generating a synthetic error page, ensuring the X-Correlation-Id header is preserved in all response types.
Description description
Environment
- Adobe Experience Manager as a Cloud Service (AEMaaCS)
- CDN configurations using
responseTransformations - Context: When implementing correlation IDs or tracing mechanisms across AEM, Dispatcher, and CDN
Issue/Symptoms
X-Correlation-Idheader is present in200 OKresponses but missing in 404 or 500 responses.- AEM logs show the header is set, but it doesn’t reach the browser or API client. Noticed when validating request tracking or debugging behavior using
cURL,Postman, or browserdeveloper tools. - Monitoring systems fail to trace failed transactions due to missing correlation headers.
- CDN configurations appear to suppress headers in error responses.
Resolution resolution
To allow AEM’s original error response and its headers to reach the client:
-
Configure your AEM error handler to include the header
x-aem-error-pass: truein error responses. -
This instructs the CDN to bypass synthetic error page generation and forward the original AEM or Dispatcher response (including its headers) directly to the client.
-
After applying this change:
- The
X-Correlation-Idheader appears in both successful and failed responses. - Client-side monitoring tools can trace the full request lifecycle accurately.
- The
Additional considerations:
- Security & compliance: Make sure error payloads don’t expose sensitive internal details before enabling this header in production.
- Scope: This behavior applies only to responses generated by AEM or Dispatcher. CDN-level errors will still serve synthetic pages.
- Common misunderstanding:
responseTransformationscan’t re-inject headers in synthetic error responses. - Testing tip: Use curl -i -v or browser developer tools to verify header presence before and after applying the fix. For example,
-i -v https:///path-that-triggers-error
Best practice recommendation:
- Always generate and set a correlation ID in backend requests.
- Include the same ID in logs and headers.
- Use
x-aem-error-pass: truefor error responses that require full traceability, especially during debugging or integration testing. - Limit usage in production to controlled scenarios to avoid overriding CDN’s standard error handling.
Related reading
- Debugging AEM as a Cloud Service using logs in AEM as a Cloud Service Tutorials.
- Configure AEM Dispatcher in AEM Dispatcher Guide.