November 7, 2026 / Sitecore

Sitecore Log Analysis: An AI Skill for Answering What Happened, When and Who Did It

Do you enjoy opening fourteen log files side by side at 2 a.m., scrolling CM and CD logs in lockstep, and trying to work out whether 09:12:04 on one server is the same moment as 09:12:04 on another? If so, this post isn’t for you. If not, read on.

The newest addition to the Sitecore AI Skills library is Sitecore Log Analysis. It’s an AI skill (and a standalone toolkit) that turns a pile of Sitecore logs into answers to the four questions every incident eventually comes down to:

What happened?
When did it happen, and in what order?
Where, meaning on which instance?
Who did it?

Why Sitecore Logs Are Harder Than They Look

The evidence is almost always in the logs. The problem is that it’s spread across:

Instances: a CM, several CDs, xConnect, Identity Server and (for headless) a rendering host, each writing its own files.
Log types: the main log, Publishing, Crawling, Search, OWIN, plus Serilog logs for xConnect, Marketing Automation, Cortex and Identity Server.
Formats: log4net, Serilog text, compact JSON, JSON lines from rendering hosts, and Application Insights exports on Azure PaaS.
Time zones: log4net lines carry a time but no date or offset. The date lives in the file name, and the time zone lives in your head (or nowhere).

On top of that, the three lines that matter are buried in thousands of routine entries. It’s not atypical to spend more time finding the evidence than understanding it.

What the Skill Does

The skill bundles a Python analyzer (sclog.py, standard library only) with six commands, each mapped to a question you’d actually ask:

Question	Command	What you get
What logs do I actually have?	`inventory`	Coverage per instance, log types, restarts with shutdown reasons (deployments show up as `ConfigurationChange`), gaps, optional SHA-256 hashes for evidence
What happened, in what order?	`timeline`	One merged, cross-instance chronology: restarts, first occurrence of each error, error bursts, publish and index jobs, risky audit actions
What are all these errors?	`errors`	Signatures grouped across CM/CD with per-instance counts, first/last seen, category, exception types and the first custom-code stack frame
Who did it?	`audit`	Sitecore’s AUDIT entries (saves, deletes, moves, publishes, template and security changes, logins, failed logins) with flags for destructive actions, broad republishes, bulk bursts and repeated failed logins
Did the deployment break anything?	`diff`	New, increased and resolved error signatures before vs. after a change, normalized per hour, with a verdict
Where else does this appear?	`search`	Regex across every log and instance, merged chronologically, optionally including stack traces

A few examples of what that looks like in practice:

python3 sclog.py timeline logs --from "2026-11-05 08:45" --to "2026-11-05 10:00"
python3 sclog.py audit logs --item "/sitecore/content/Home/Promotions" --action "delete|recycle"
python3 sclog.py diff logs --split "2026-11-05 21:30"

Each command writes a Markdown report (and CSV where it helps) that’s small enough to read, attach to a ticket, or hand to an AI assistant.

Who Deleted That Page?

This is the question that comes up most, and it’s usually asked in a hurry. Sitecore already records the answer: AUDIT entries on the CM capture the account, the action, the item path, language, version and ID. The audit command pulls those out and classifies them (Destructive, Security, Publishing, Structure, Workflow, Content change, Session, Auth failure). It then answers in one line who recycled the item, when, and from which instance.

It’s critical to know the limits too, and the skill states them plainly. AUDIT entries record who did what, not the field values before and after. Custom code, imports and some scripts can bypass auditing entirely. Missing an entry isn’t proof nothing happened. For the values themselves, you still need version history, the Recycle Bin/Archive or a backup.

Did Last Night’s Deployment Break Anything?

The diff command is the one I’d put into every release checklist. Point it at logs that span the deployment with a split time, or at a baseline window (ex. the same time slot last week) and the current one. You get:

NEW signatures that didn’t exist before the change. This is the strongest regression signal.
INCREASED signatures, meaning existing problems that got worse (2× or more per hour by default).
RESOLVED signatures, which belong in your release notes.

Compare like with like. Traffic and scheduled jobs at 3 a.m. are nothing like 3 p.m.

No Server Access? No Problem

Plenty of Sitecore administrators can log in to Sitecore but can’t reach the server’s file system. That’s especially common on Managed Cloud and locked-down enterprise environments. The skill includes collect-logs.ps1, a read-only Sitecore PowerShell Extensions script. You run it in the SPE ISE on the CM and it:

Finds the instance’s log folder.
Selects the logs for the date range you choose.
Zips them (including the log file currently being written).
Adds a manifest with the machine name, role and time zone.
Downloads the zip to your browser.

sclog.py reads the zip directly and applies the manifest’s UTC offset automatically, so that instance lines up with the others in the timeline.

On SitecoreAI, CM logs come from the Deploy app or the Sitecore CLI and use the same format, so everything above works unchanged. On Azure PaaS, the skill includes the KQL to export Application Insights traces to CSV, which sclog.py reads with the role instance as the server name.

Using It With (or Without) AI

With Claude: install the skill (copy the folder into ~/.claude/skills/ for Claude Code, or upload it under Settings ? Capabilities ? Skills in the Claude apps). Then attach your logs and ask the question the way you’d ask a colleague:

“The site threw 500s from 9:05 to 9:40. Logs from the CM and both CDs attached. What happened?”
“Who deleted /Home/Promotions/Black Friday, and when?”
“We deployed at 9:30 last night. Did we introduce anything?”

The skill has Claude confirm coverage first, run the right analysis, and answer in one or two sentences backed by the exact log lines. It says how confident it is and what evidence is missing when the logs can’t settle the question.

Without Claude: run sclog.py directly. Follow the investigation playbook that ships with the skill for incidents, deployment checks and security reviews, including an incident report template. Or load the SKILL.md into the AI assistant your organization uses.

How It Fits With the Other Log Skill

The library already has Log & Performance Diagnostics, which focuses on tuning: timing and item thresholds, IIS response times, cache sizing and rendering statistics. Log Analysis focuses on investigation: timelines, audit trails, regressions and searching across every log type and instance. For a “the site is slow and nobody knows why” incident, use both.

A Few Practical Habits

Keep original file names. log4net lines carry only a time; the date comes from the name.
Collect from every instance involved, not just the one that’s complaining. A signature on one CD points at that server; on every CD it points at shared code, config or content.
Note each server’s time zone, or use the collector’s manifest. Ordering events across servers is only as good as the clocks.
Collect promptly. The Sitecore cleanup agent deletes old logs (commonly after 30 days).
If it looks like a compromise, preserve the originals (inventory --hash), work on copies, and bring in your security team before touching the servers.

The skill is free and MIT licensed, like the rest of the AI Skills Library. If you put it through its paces on a real XP or SitecoreAI incident, or there’s a log format it should understand that it doesn’t yet, open an issue on the repo. Real-world logs are what will make the next version better.