Separating Sitecore Audit Logs into a Dedicated Log File in Sitecore 10.4

 Introduction

In a Sitecore implementation, application, publishing, and audit messages are often written to the standard Sitecore log files. When troubleshooting or reviewing user activities, finding audit-related entries in a large Sitecore log can become time-consuming.

A simple approach to address this is to configure a dedicated Audit Log file that captures Sitecore AUDIT entries separately.

This provides a cleaner and more manageable way to review activities such as content updates, publishing, and user actions without having to search through the complete Sitecore log.

What is Sitecore Audit Logging?

Sitecore generates audit-related log entries for various activities performed within the Sitecore application.

For example:

AUDIT (sitecore\Admin): Save item: master:/sitecore/content/Home/Sample Item,
language: en, version: 1, id: {3ABBD7F1-9C9A-442A-8899-5DE37BFB9B65}

This entry provides useful information such as:

  • User who performed the action

  • Action performed

  • Database

  • Item path

  • Language

  • Version

  • Item ID

  • Time of the activity

Publishing actions can also generate entries such as:

AUDIT (sitecore\Admin): Publish item: master:/sitecore/content/Home/Sample Item,
language: en, version: 1, id: {3ABBD7F1-9C9A-442A-8899-5DE37BFB9B65}

This makes the audit log useful when investigating content changes and publishing activities.

Do We Need to Enable Audit Logging?

For Sitecore 10.4, there is no need to introduce a separate custom mechanism just to start generating the standard Sitecore audit information.

The proposed configuration does not enable a new audit mechanism. Instead, it takes the existing AUDIT entries generated by Sitecore and routes them to a dedicated log file.

Therefore, the purpose of the configuration patch is log separation, not enabling audit functionality.

Why Separate the Audit Log?

Keeping audit entries in a dedicated file provides several benefits.

1. Easier Troubleshooting

Instead of searching through large Sitecore logs, administrators can directly open:

App_Data\logs\Audit.log.{date}.txt

and review audit-related activity.

2. Easier User Activity Tracking

The audit entries can help identify which user performed actions such as:

  • Saving content

  • Publishing content

  • Other Sitecore audit activities

3. Easier Monitoring

A dedicated audit file can be monitored independently from the standard Sitecore logs.

4. No Additional Database Logging

If the requirement is only to maintain the audit information in a file, there is no need to configure an SQL appender.

The proposed configuration writes the audit entries only to the dedicated log file.

Configuration Patch

The recommended approach is to create a separate patch file rather than modifying the Sitecore configuration directly.

Suggested location:

App_Config\Include\zzz\zzz.AuditLog.config

The configuration can be:

<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"
               xmlns:x="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <log4net>

      <!-- Audit / Publishing log file -->
      <appender name="AuditLogFileAppender"
                type="log4net.Appender.SitecoreLogFileAppender, Sitecore.Logging">

        <file value="$(dataFolder)/logs/MuseumAudit.log.{date}.txt" />

        <!-- AUDIT messages -->
        <filter type="log4net.Filter.StringMatchFilter">
          <stringToMatch value="AUDIT" />
          <acceptOnMatch value="true" />
        </filter>

        <!-- Publishing messages -->
        <filter type="log4net.Filter.StringMatchFilter">
          <stringToMatch value="[Publishing]" />
          <acceptOnMatch value="true" />
        </filter>

        <!-- PublishOptions messages -->
        <filter type="log4net.Filter.StringMatchFilter">
          <stringToMatch value="[PublishOptions]" />
          <acceptOnMatch value="true" />
        </filter>

        <!-- Reject everything else -->
        <filter type="log4net.Filter.DenyAllFilter" />

        <appendToFile value="true" />
        <rollingStyle value="Date" />
        <maxSizeRollBackups value="-1" />

        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="%4t %d{ABSOLUTE} %-5p %m%n" />
        </layout>

        <encoding value="utf-8" />

      </appender>

      <!-- Root logger -->
      <root>
        <priority value="INFO" />
        <appender-ref ref="AuditLogFileAppender" />
      </root>

      <!-- Audit logger -->
      <logger name="AuditLogFileAppender" additivity="false">
        <level value="INFO" />
        <appender-ref ref="AuditLogFileAppender" />
      </logger>

      <!-- Sitecore Publishing logger -->
      <logger name="Sitecore.Diagnostics.Publishing" additivity="false">
        <level value="INFO" />
        <appender-ref ref="AuditLogFileAppender" />
      </logger>

    </log4net>
  </sitecore>
</configuration>

Why Use Only the AUDIT Filter?

Sitecore publishing can generate different types of log messages, including:

These messages are useful for publishing troubleshooting, but they are not necessarily required when the objective is to maintain a clean audit trail.

The AUDIT entries themselves already provide useful information about the activity.

For example:

AUDIT (sitecore\Admin): Save item: master:/sitecore/content/Home/Sample Item,
language: en, version: 1, id: {3ABBD7F1-9C9A-442A-8899-5DE37BFB9B65}

and:

AUDIT (sitecore\Admin): Publish item: master:/sitecore/content/Home/Sample Item,
language: en, version: 1, id: {3ABBD7F1-9C9A-442A-8899-5DE37BFB9B65}

Therefore, using only the AUDIT filter keeps the dedicated file focused on audit activity.

Log File Location

After applying the patch, the audit log will be generated under:

<Data Folder>\logs\Audit.log.{date}.txt

For example:

App_Data\logs\Audit.log.2026-08-23.txt

The log file will roll based on the configured date-based rolling strategy.

SQL Appender Is Not Required

If the requirement is to store audit information only in files, an SQL appender should not be configured.

The following should not be included:

<appender name="ADONetAppender_SqlServer" ...>

and:

<appender-ref ref="ADONetAppender_SqlServer"/>

This ensures that the audit entries are not additionally inserted into a SQL Log table.

The flow is therefore:

Sitecore Activity
       ↓
   AUDIT Event
       ↓
AuditLogFileAppender
       ↓
Audit.log.{date}.txt

Example Audit Entries

Content Save

AUDIT (sitecore\Admin): Save item:
master:/sitecore/content/Home/Sample Item,
language: en, version: 1,
id: {3ABBD7F1-9C9A-442A-8899-5DE37BFB9B65}

Content Publish

AUDIT (sitecore\Admin): Publish item:
master:/sitecore/content/Home/Sample Item,
language: en, version: 1,
id: {3ABBD7F1-9C9A-442A-8899-5DE37BFB9B65}

These entries allow the team to identify the user, action, item, language, version, and timestamp associated with the activity.

Validation

After deploying the configuration patch to the CM server, perform a few test activities:

  1. Log in to Sitecore.

  2. Modify and save a test item.

  3. Publish the test item.

  4. Check the audit log under:

App_Data\logs\Audit.log.{date}.txt

  1. Verify that the expected AUDIT entries are present.

  2. Confirm that the standard Sitecore log is no longer the only place where these audit entries need to be searched.

  3. Confirm that no SQL logging is configured for the audit appender.

Conclusion

Separating Sitecore audit entries into a dedicated log file provides a simple way to improve audit visibility and troubleshooting.

The approach does not introduce a new audit mechanism. Instead, it uses the existing Sitecore audit events and routes the AUDIT entries to:

App_Data\logs\Audit.log.{date}.txt

For Sitecore 10.4, this provides a cleaner separation between audit activity and the broader Sitecore application logs, while avoiding unnecessary SQL-based audit logging when file-based logging is sufficient.

Comments

Post a Comment

Popular posts from this blog

Configuring Custom Media Domain in Sitecore XP 10 + Next.js

Image
Enabling Custom Domain URLs for Media Files in a Sitecore Headless (JSS + Next.js) Project Recently, while working on a Sitecore XP 10 solution integrated with Next.js (JSS) , I came across a requirement to serve media assets via a custom domain instead of the default Sitecore CM/CD URLs. This is a common scenario when optimizing for performance, SEO, and CDN configurations — especially when you want to serve images from a brand-specific or region-specific domain like https://Customdomain.com instead of the default https://sitecore-cd.azurewebsites.net . Step 1: Define Media Base URL in Next.js In your Next.js environment configuration , add a new variable to define the media domain: NEXT_PUBLIC_MEDIA_BASE_URL= https://Customdomain.com   This allows your front-end components to dynamically resolve Sitecore media URLs from the correct domain at runtime. Step 2: Configure Site Definition in Sitecore Next, you need to update the Sitecore site definition to use the same domai...
Read more

Building a CMS-Agnostic Layout Service Response in Sitecore

Image
Building a CMS-Agnostic Layout Service Response in Sitecore   Introduction In modern headless architectures, frontend teams (especially Next.js) expect clean, predictable, and CMS-agnostic APIs. However, Sitecore Layout Service by default returns: Nested fields.value structures Media, links, and other field types follow Sitecore-specific structures CMS-specific field types This makes frontend consumption complex and tightly coupled to Sitecore. In this blog, I’ll walk through how I built a CMS-agnostic Layout Service response, including solving one of the trickiest problems: 👉 Expanding Multilist fields dynamically with full field data  Problem Statement Sitecore Layout Service provides a powerful way to expose content for headless applications. However, the default response is highly CMS-dependent and not ideal for modern frontend frameworks like Next.js. For example: Fields are wrapped in fields.value Field names are not normalized Media, links, and other fi...
Read more

Sitecore 10.4 + Docker + Next.js: A Complete Setup Guide for JSS Developers

Image
  Setting Up Sitecore xp 10.4 with Docker and Next.js (JSS Connected Mode) Setting up a modern Sitecore solution using Docker and Next.js enables rapid local development with a clean separation of front-end and back-end concerns. In this post, we’ll walk through how to set up Sitecore XP 10.4  using Docker along with Next.js in connected mode , using Sitecore JSS Prerequisites Before starting, make sure you have the following installed: Windows 10/11 Pro or Enterprise (for Docker Desktop with Hyper-V) Docker Desktop (configured for Windows containers) .NET SDK 6.0+ Node.js v18+ Git Sitecore Container Deployment Packages (WDPs) Sitecore License File JSS CLI Steps:    1. Enable hyer-v      Control panel --->programs --> program and feature 2. Download and Install docker using below link        Click here to download and install docker 3. Install the template   Open PowerShell with administ...
Read more