Back in the day, there used to only be the log file when you needed to find out why something might be broken. Today, it’s a bit more complicated today, but honestly, not terribly. We’ll have a look at where to find them, which ones to look for depending on the error you’re having, and what you can do if you want to add additional logging if there is a publishing issue.
Log in to the XM Cloud Portal at https://portal.sitecorecloud.io and once on the main page, you will find
Manage my projects. Click that to see a list of your projects according to your setup.
On the next page, select the appropriate project. You will then be taken to the environment list. An example is shown below. Clicking the
Options button the right will open a drop down and then you can select
View environment logs.
When the logging page loads, you’ll see a familiar list of log file names, and some new ones.
The two logs that you’ll visit most often will be the
Log and those started with
Log entry will contain the logs associated with the Content Management instance. The
RenderingHost logs will be any log entries related to, but not limited to, the Experience Editor / Pages as well as the deployment of the Front-End Headless environment. Note: This is not the logs for any hosting environment, such as Vercel. The logs for that environment will be in that system.
When you kick off a deployment manually or have an auto deployment kicked off because of a check-in, you can go in and basically watch the deployment process happen. There are two main areas you need to pay attention to.
Build, the important parts, besides any issues related to your solution building, you can also verify the serialization process. Within
Deployment, you can watch the front-end piece being installed and validate any build, errors, linting, etc., that may need remediation.
Sometimes during deployment, when it fails, it’s not immediately obvious what may be the cause, as in this case. It turned out that this was a known issue, and Sitecore was already investigating. It was just a bad-timed deployment, but if you do see an error like the following, copy it and attach it to a support ticket, along with the appropriate project and environment details.
The project and environment details you’ll find back on the environment page by clicking the environment name and then expanding the bar at the top to see the appropriate environment details.
There are cases when the logs are just not showing enough detail. I experienced this when I had an issue with publishing. I was trying to push a bunch of media (images) up to Experience Edge, and one of those images was breaking, but I wasn’t sure which.
In comes debug mode.
Head back to the environment listing page where we initially went to see the environment logs in the
Options drop-down menu. This time though, you’re going to select
Environment variables as shown below.
A fly-out from the right side will list the existing environment variables and allow you to create new ones if needed. What we’re looking for, though, is already listed. It’s
LOG_LEVEL_VALUE. We need to change the value from INFO to
This will allow us to see greater detail in our logs. In our case, we were able to see the item being published *prior* to it failing, and thus we found the broken item. In our case, an item without a template was causing the publishing failure.
While the LOG_LEVEL_VALUE change only affects the Log file specifically, you can enhance Publishing logging through the use of a config file addition to your solution. Hat time to Andy Cohen for helping us with this.
<configuration xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:patch="http://www.sitecore.net/xmlconfig/" > <sitecore role:require="Standalone or ContentManagement or XMCloud"> <log4net> <logger name="Sitecore.Diagnostics.Publishing"> <level> <patch:attribute name="value" value="DEBUG"/> </level> </logger> </log4net> </sitecore> </configuration>
After speaking with Sitecore on this topic, there are improvements coming to the interface for XM Cloud that would allow for easy downloading of logs, etc. This will make searching for them much easier as you can then use any tool at your disposal.
I would also really, really appreciate that any time a null error or an error such as the following occurred, the exception would contain the GUID of the item when the error occurred. This goes not just for publishing but any exception and perhaps one of my biggest issues with exceptions.
Awesome enhancements like adding Slack webhooks to get notified of when a deployment is started, errored or finished would be extremely handy, so we know when the latest version has been deployed or if it failed, why.
Sign up to our bi-weekly newsletter for a bite-sized curation of valuable insight from the Sitecore community.