Overview
This article is for IT administrators and MSP technicians who need to:
Determine whether SentinelOne is causing high CPU or slow applications
Identify which applications the agent spends the most time monitoring
Create focused exclusions that address business app performance without unnecessarily weakening security
Guardz deploys and manages SentinelOne for your environment. This guide walks you through SentinelOne's Agent Activity Analyzer and shows you how to turn those findings into exclusions, in Guardz where possible, or in the SentinelOne console when needed.
What Is the Agent Activity Analyzer?
The Agent Activity Analyzer is a built-in SentinelOne troubleshooting tool. It produces a text report showing:
The data collection window (start and end time)
When the agent started and stopped
Which processes used the most agent time (as a percentage and in absolute minutes/seconds)
Agent CPU usage (average and peak), typically sampled in 5-minute intervals
Security software must closely monitor other programs—and sometimes that creates friction: high CPU, slow backups, or laggy line-of-business apps. The analyzer pinpoints which process is driving agent workload so you can add a narrow, targeted exclusion rather than broadly reducing protection.
Scope of this feature SentinelOne designed the Activity Analyzer primarily for interoperability issues that manifest as high agent CPU. Other issue types may be supported in future agent versions. |
When to Run a Report?
Run an Activity Analyzer report when you observe any of the following:
High CPU on a workstation or server, and you suspect SentinelOne involvement
High CPU specifically on the SentinelOne agent process
Applications that became noticeably slower after SentinelOne was installed
Problems tied to a specific time window (you can pull a report scoped to that window)
Before you start Note the exact date and time of the problem before generating a report. You will need this if you run a custom time-window report directly on the endpoint. |
Reading the Report
Field | What It Means |
Start / end time | The period covered by the report |
Agent start / stop events | Whether the agent restarted during the period |
% of agent activity time per process | Relative share of the agent's effort per application |
Absolute time per process | Actual time the agent spent on each application |
Agent average / max CPU | How hard the agent itself was working (in 5-minute samples) |
How to Interpret Results
Look for processes at the top of the list by percent of agent activity time.
Confirm with absolute time — a high percentage over a short window can still be meaningful.
Cross-reference with agent CPU spikes in the same time range.
If a process ranks high during known slowness, it may be a candidate for an exclusion — only after completing the safety checks below.
System processes in results Some entries may show as a system process rather than a file path (e.g., registry-related activity or PID 4). This is normal. Contact your MSP or support if you are unsure how to handle those rows. |
Generating a Report
You can generate reports from the SentinelOne Management Console or directly on the Windows endpoint.
Method 1: SentinelOne Management Console (Recommended)
Requirements: Windows agent 4.6 or newer; console access with Fetch Logs permission (included for Guardz Console Access users).
File | Time Covered |
LatestActivityAnalyzerReport.txt | Last 2 hours |
FullActivityAnalyzerReport.txt | Last 48 hours |
Sign in to the SentinelOne Management Console.
Open Sentinels and select the affected endpoint.
Click Actions → Troubleshooting → Fetch Logs.
Select Agent Logs, then click Fetch Logs.
Navigate to Activity → Administrative → Log operations and locate the upload confirmation entry.
Download the archive, extract it, and open the Activity Analyzer .txt file.
Method 2: On the Endpoint with sentinelctl (Custom Time Windows)
Requirements: Windows agent 4.5.1 or newer; Administrator Command Prompt on the affected machine.
Open Command Prompt as Administrator.
Navigate to the SentinelOne agent folder (version number varies):
cd "C:\Program Files\SentinelOne\Sentinel Agent [your version]"
Run one of the commands below.
Last 4 hours (default)
sentinelctl create_agent_analyzer_report -o "C:\Temp\activity_report.txt"
Specific time window (UTC) — use when you know exactly when the problem occurred:
sentinelctl create_agent_analyzer_report -o "C:\Temp\activity_report.txt" -s "12:30 06-11-2020" -e "13:25 06-11-2020"
Time format: hh:mm dd-mm-yyyy (UTC)
Last X minutes:
sentinelctl create_agent_analyzer_report -o "C:\Temp\activity_report.txt" -m 120
(Example above = last 120 minutes)
From Report to Exclusion: The Guardz Workflow
Follow these steps every time to keep exclusions safe and auditable.
Step 1 — Reproduce and Collect
• Confirm the symptom (high CPU, slowness, errors).
• Generate a report covering the incident window (console 2h/48h, or sentinelctl custom window).
Step 2 — Identify the Top Process
• Find the process with the highest percentage and absolute agent time.
• Verify it matches a real business application you recognise.
Step 3 — Safety Check
Do not exclude these processes Web browsers (Chrome, Edge, Firefox, and similar) Microsoft Office applications (Word, Excel, Outlook, etc.) Other security-sensitive or high-risk processes
If any of these appears at the top of the report, stop and contact your MSP or Guardz support. Do not create an exclusion on your own. |
Step 4 — Choose the Narrowest Exclusion Type
If the report shows… | Consider this exclusion type |
One known .exe path (backup, ERP, RMM, etc.) | Path (file or folder) |
Same software, path changes after updates | Hash (SHA1) |
Many files of one type in one area | File type (use sparingly) |
One trusted software vendor | Signer identity (certificate) |
Script / command line (last resort) | Command line — very broad, use rarely |
Step 5 — Choose the Lowest Suppression Mode
For CPU/interoperability issues, start with the least aggressive option and escalate only if needed:
Mode | When to use |
Interoperability | Good first choice for in-process monitoring friction |
Interoperability (extended) | If the first mode did not resolve the issue |
Performance Focus | Disables all monitors for the path — use only if proven necessary |
Performance Focus (extended) | Strongest trade-off; use rarely |
Step 6 — Apply at the Correct Scope
Scope | When to use |
One site / one customer | Problem affects a single organisation |
Account (MSP-wide) | Same trusted app across many customers — test on one machine first |
Global | Rare; requires strict change control |
Step 7 — Validate
• Wait for policy to apply (typically a few minutes).
• Reproduce the user workflow that originally caused the problem.
• Generate a new Activity Analyzer report covering a similar time window.
• Confirm the target process dropped in the rankings and agent CPU improved.
• Log the change: ticket number, endpoint, process, exclusion type/mode, date, and before/after notes.
Non-negotiable rules for every exclusion Every exclusion is a security exception for matching activity. Never exclude browsers, Microsoft Office, or other 'not recommended' processes without vendor or support guidance. Prefer exact path or hash over broad folders or file type wildcards. Prefer Interoperability mode over disabling all monitors unless testing proves a stronger setting is required. Review exclusions periodically and remove any for software no longer in use. Document every change: who made it, why, the scope applied, and validation outcome. |