SharePoint ULS Logs: Where They Are, How to Configure and Read Them

A user hits “Sorry, something went wrong” and all you get is a correlation ID. On SharePoint Server, that ID is your way into the trace logs, where the real exception is written.

In this tutorial, we’ll show you where SharePoint ULS logs live, how to configure diagnostic logging, how to pull one request out of them with PowerShell, and what to use in SharePoint Online instead.

Quick answer: SharePoint ULS logs are the Unified Logging Service trace files each SharePoint Server writes to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS by default. Configure them in Central Administration under Monitoring > Reporting > Configure diagnostic logging, and find an error with Merge-SPLogFile -Correlation plus a time range.

What You Need Before You Start

• SharePoint Server Subscription Edition, 2019 or 2016 (2013 works the same with a 15 folder). Our SharePoint Server Subscription Edition guide covers setup.
• Membership in the Farm Administrators group for Central Administration.
• For PowerShell: local Administrators on the server plus SharePoint Shell access (Add-SPShellAdmin). Use Windows PowerShell 5.1, not PowerShell 7.

What Are SharePoint ULS Logs?

Every server in the farm writes its own trace files, so an error on one web front end never shows up in another server’s folder. Keep that in mind in a multi-server SharePoint farm architecture.

Each line is one event with a timestamp, process (w3wp.exe for web requests, OWSTIMER.EXE for timer jobs), area, category, event ID, level, message and correlation ID. SharePoint starts a new file every 30 minutes by default.

Trace levels run from Unexpected through Monitorable, High, Medium and Verbose to VerboseEx (PowerShell only). ULS logs are for troubleshooting, not an audit trail.

Step 1: Find the ULS Logs Folder

SharePoint Server 2016, 2019 and Subscription Edition all use the 16 hive. If someone moved the logs, the configured path wins, so ask the farm instead of guessing:

# Where are the logs, how long are they kept, and is there a size cap?
Get-SPDiagnosticConfig | Select-Object LogLocation, DaysToKeepLogs, LogCutInterval, LogMaxDiskSpaceUsageEnabled, LogDiskSpaceUsageGB

LogLocation is the folder on every server, DaysToKeepLogs defaults to 14, and LogCutInterval is the 30-minute rollover. The same shell also tells you which SharePoint version and build you run, which support will ask for.

Step 2: Configure Diagnostic Logging in Central Administration

These settings apply to the whole farm:

1. In Central Administration, select Monitoring, then Configure diagnostic logging under Reporting.
2. Under Event Throttling, pick All Categories or specific ones, then set Least critical event to report to the event log and to the trace log.
3. Leave Enable Event Log Flood Protection checked so repeated events don’t flood the Windows event log.
4. Under Trace Log, enter the Path and the Number of days to store log files (1-366).
5. Check Restrict Trace Log disk space usage, enter a size in GB, and select OK.

Disk space is unlimited by default, and the logs land on the install drive. We always move them and set a cap. The PowerShell equivalent, also in our SharePoint PowerShell commands cheat sheet, is:

# Move the trace logs off the system drive and keep 7 days
Set-SPDiagnosticConfig -LogLocation "D:\ULSLogs" -DaysToKeepLogs 7

# Cap the trace logs at 50 GB (the switch takes no $true)
Set-SPDiagnosticConfig -LogMaxDiskSpaceUsageEnabled -LogDiskSpaceUsageGB 50

# Review the current trace and event levels per category
Get-SPLogLevel

When the cap is reached, SharePoint deletes the oldest files first.

Turn up logging for one problem, then turn it back down

Levels don’t reset on their own, and Verbose left on fills drives fast. Raise one area, cut a new file, reproduce, then reset:

# Verbose tracing for every category in one area while you reproduce the problem
Set-SPLogLevel -TraceSeverity Verbose -Identity "SharePoint Foundation:*"

# Start a fresh log file so the repro is easy to find
New-SPLogFile

# ...reproduce the problem...

# Put every category back to its default level
Clear-SPLogLevel

Step 3: Find an Error by Correlation ID

The correlation ID on an error page appears in every log line for that request, on every server it touched. (A client-side error like Sorry, something went wrong in an SPFx form customizer needs the browser console too.) Merge-SPLogFile searches all farm servers and writes the matches to one local file:

Merge-SPLogFile -Path "C:\Logs\Correlation.log" `
    -Correlation "8dd40978-53aa-4f0a-a51c-fedf16dd974b" `
    -StartTime "10/20/2026 8:00 AM" -EndTime "10/20/2026 10:00 AM" -Overwrite

Without -StartTime, it only looks at the last hour. If nothing matches, it writes a warning instead of a file. On a single server, filter Get-SPLogEvent on the Correlation property:

Get-SPLogEvent -StartTime (Get-Date).AddHours(-3) |
    Where-Object { $_.Correlation -eq "8dd40978-53aa-4f0a-a51c-fedf16dd974b" } |
    Format-List Timestamp, Area, Category, Level, Message

Step 4: Filter ULS Logs with Get-SPLogEvent

Get-SPLogEvent returns entries as objects. It accepts -StartTime, -EndTime, -MinimumLevel (Error or Warning), -Directory and -File, so everything else goes through Where-Object:

# Errors from the last hour on this server
Get-SPLogEvent -StartTime (Get-Date).AddHours(-1) -MinimumLevel Error

# Warnings and errors in one category, as a table
Get-SPLogEvent -StartTime (Get-Date).AddHours(-2) -MinimumLevel Warning |
    Where-Object { $_.Category -eq "Database" } |
    Format-Table Timestamp, Area, Category, Level, Message -AutoSize

# A fixed window from a merged file
Get-SPLogEvent -File "C:\Logs\Correlation.log" -StartTime "10/20/2026 8:00 AM" -EndTime "10/20/2026 10:00 AM"

Always give a start time: with no parameters, the cmdlet reads every log file on the server. Dates are culture-specific, so we use the US format shown.

Step 5: Open the Logs in ULS Viewer

ULS Viewer is Microsoft’s free log reader. It filters by correlation ID, level, area or category, highlights rows, and can follow a log folder live while you reproduce an issue.

Get it only from the Microsoft Download Center (link in the FAQ), never a mirror site. It’s a 196 KB ulsviewer.zip (version Aug2014) with no installer. Microsoft lists it for SharePoint 2013 and older Windows, so if it won’t run on a server, copy the .log files to a workstation.

ULS Cmdlet Cheat Sheet

Cmdlet	What it does	Watch out for
Get-SPDiagnosticConfig	Shows log path, retention and size cap	Read-only
Set-SPDiagnosticConfig	Changes path, days (1-366), size cap	-LogMaxDiskSpaceUsageEnabled is a switch
Set-SPLogLevel / Clear-SPLogLevel	Raises or resets trace and event levels	Reset after Verbose
New-SPLogFile	Ends the current file and starts a new one	Runs on the local server
Merge-SPLogFile	Collects matches from every server	Last hour only without -StartTime
Get-SPLogEvent	Queries one server’s logs or a file	No -Correlation parameter

Does SharePoint Online Have ULS Logs?

SharePoint in Microsoft 365 writes ULS logs too, but Microsoft doesn’t give customers copies or access, even through a support case. Diagnostic logging settings don’t apply there either.

Use these instead. Most of them work from the shell you use to connect to SharePoint Online with PowerShell or the admin centers:

• Correlation ID + time: copy both from the error page into a Microsoft support request; the engineers look up the logs for you.
• Microsoft Purview audit log: in the Microsoft Purview portal, open Audit and search SharePoint file, folder and site activity (needs the Audit Logs or View-Only Audit Logs role).
• Service health: in the Microsoft 365 admin center, check Health > Service health before you troubleshoot an outage locally.

Common Mistakes to Avoid

• Searching one server: the failing request may have run on another web front end. Use Merge-SPLogFile.
• Forgetting the time range: Merge-SPLogFile defaults to the last hour, so yesterday’s error returns nothing.
• Leaving Verbose on: run Clear-SPLogLevel when you’re done.
• Passing $true to a switch: write -LogMaxDiskSpaceUsageEnabled alone.
• No disk cap: unlimited logs on the system drive can fill it and stop the server.

Next Steps

Once logging is under control, the next farm task is usually creating a web application in SharePoint Server.

We’d keep these SharePoint Server guides handy too:

• SharePoint Server 2019 [Features and Deployment Best Practices]
• Hardware and Software Requirements for SharePoint Server Subscription Edition and SharePoint Server 2019
• SharePoint Server Object Model Tutorial
• SharePoint Online Management Shell

Frequently Asked Questions