Context
In the transition from traditional Sitecore XP to XM Cloud headless architecture, one of the most significant shifts is how CMS errors are managed. In traditional PaaS implementations, Sitecore XP handled most exceptions through a centralized system with log files easily accessible on the server file system. With a move to SaaS, a different approach needs to be considered.
Execution
With XM Cloud's cloud-native architecture, error management follows a different approach:
- Logs are no longer accessed through file systems but through the XM Cloud Portal.
- Errors can occur across multiple distributed services - Content Management, Layout Service or Experience Edge.
- CMS errors (XM Cloud services) and web errors (Rendering Host) are managed separately
Without understanding these changes, organizations risk missing critical errors, creating debugging challenges, and experiencing prolonged resolution times. Many XP customers migrating to XM Cloud don't realize they need to adapt their error monitoring strategies for this new environment.
Accessing XM Cloud Portal Logs
The XM Cloud Portal Logs can be accessed through the XM Cloud Deploy app:
- Log into XM Cloud Deploy app
- On the navigation pane, click Projects
- On the Projects page, click the project that contains the environment you want to investigate
- On the project page, click the environment you want
- On the environment page, click Logs
For developers and DevOps professionals who prefer command-line tools or need to automate log access, Sitecore Cloud CLI provides robust options. Common usages as follow:
-
Listing Available Logs:
dotnet sitecore cloud environment log list -id <environment-id> --latest -
Viewing Log Contents in Terminal:
dotnet sitecore cloud environment log view --environment-id <env-id> --filename <filename> -
Downloading Log Files:
dotnet sitecore cloud environment log download --environment-id <env-id> --filename <filename> -
Accessing Deployment Logs:
dotnet sitecore cloud deployment log --deployment-id <id> --output <path>
Logs are categorized by three areas:
- Log: Contains Content Management (CM) instance-related exceptions
- RenderingHost: Contains logs related to Experience Editor/Pages and headless frontend deployment
- Deployment: Contains build and deployment process logs
Read more detail on the Manage an environment and Deployment Log documentation.
Enhancing Logging for Better Visibility
When standard logs don't provide enough detail, use the enhanced logging options
Navigate to your environment in XM Cloud Portal, select "Variables" from the Tablist and find LOG_LEVEL_VALUE and change it from INFO to DEBUG.
For enhanced Logging, make sure to enable enhanced logging temporarily for troubleshooting specific issues. Return to standard logging levels after resolution to avoid log bloat and document specific error patterns for future troubleshooting
Hosting Platform Logs vs. XM Cloud Logs
When troubleshooting issues in your headless implementation, knowing which logging system to check first can save significant time. XM Cloud logs only tell part of the story - your hosting platform logs (Vercel, Azure, AWS, etc.) contain critical information about the frontend rendering and delivery.
| When to check XM Cloud Logs | When to check Hosting Platform Logs |
|---|---|
|
|
For detailed instructions on accessing logs for your specific hosting platform, refer to the official documentation:
- Vercel Log Documentation
- Netlify Log Documentation
- Azure App Service Logs Documentation
- AWS Amplify Logs Documentation
Insights
Cross-system issues often occur at the integration points between XM Cloud and your hosting platform. These scenarios require investigating both systems to correctly identify the root cause.
Example 1: Content appears in XM Cloud but not on website
This common issue occurs when content has been successfully authored and published in XM Cloud, but visitors can't see the updates on the website. This disconnect typically happens at the handoff between content delivery and frontend rendering.
Troubleshooting steps:
- First check XM Cloud logs for publishing errors - verify content has been successfully published to Experience Edge
- If publishing is successful, check hosting platform build logs - some headless implementations trigger rebuilds on content changes
- Look for API connection errors in the hosting platform logs - examine if the frontend can connect to Experience Edge
- Verify Experience Edge connectivity from your hosted environment - network restrictions or misconfigured endpoints could prevent content retrieval
Example 2: Website showing incorrect or outdated content
When visitors see stale or incorrect content despite updates in XM Cloud, caching is often the culprit. Multiple caching layers in a headless architecture can each retain outdated content.
Troubleshooting steps:
- Check XM Cloud logs for publication success - confirm content changes were properly published
- Check hosting platform logs for successful build after publication - ensure the frontend application processed the content updates
- Examine caching configurations in both systems - XM Cloud CDN caching, Experience Edge caching, and hosting platform caching all play a role
- Look for invalidation errors in Edge CDN logs - cache invalidation failures can prevent updated content from being served