How to Stop Wazuh File Integrity Monitoring From Eating Your CPU

File Integrity Monitoring (FIM) is one of the most valuable security capabilities in Wazuh.

It helps security teams detect unauthorized changes to files, directories, registry keys, and critical system configurations that could indicate malware infections, insider threats, ransomware activity, or unauthorized administrative actions.

However, many Wazuh administrators eventually encounter a frustrating problem: unexpectedly high CPU utilization caused by the FIM module.

In some environments, FIM can consume significant system resources, especially when monitoring large file systems, high-churn directories, or servers with millions of files.

When CPU usage becomes excessive, it can impact endpoint performance, slow down security monitoring, delay alert generation, and create operational challenges across the entire Wazuh deployment.

In this guide, you’ll learn why Wazuh File Integrity Monitoring can generate high CPU usage, how the FIM engine works internally, the most common causes of resource spikes, and the practical tuning strategies that can dramatically reduce CPU consumption without sacrificing visibility into critical file changes.

Why FIM Can Become a Major Source of CPU Consumption

The same mechanisms that make FIM effective are also responsible for its resource usage.

Every monitored file must be examined, hashed, compared against previous baselines, and tracked for metadata changes.

In small environments this overhead is minimal, but in larger deployments it can become substantial.

CPU consumption typically increases when:

• Monitoring very large directory trees
• Hashing large numbers of files
• Tracking frequently changing application data
• Running frequent scheduled scans
• Monitoring log directories with constant updates
• Performing real-time monitoring on busy servers

Security engineers frequently underestimate how much work the agent must perform during a full scan.

Each file operation requires multiple checks, and those checks multiply rapidly across hundreds of thousands or millions of files.

Symptoms of Wazuh Integrity Monitoring High CPU Usage

High CPU utilization caused by FIM usually presents itself in several recognizable ways.

Common symptoms include:

• Wazuh agent processes consistently consuming high CPU
• CPU spikes during Syscheck scans
• Servers becoming sluggish during integrity checks
• Increased disk utilization alongside CPU usage
• Delayed alert generation
• Longer scan completion times
• Excessive hashing activity
• User complaints about application performance

Administrators often first notice the issue through tools such as:

• top
• htop
• Task Manager
• Performance Monitor
• OpenSearch dashboards
• Infrastructure monitoring platforms

In some cases, the Wazuh agent may appear near the top of CPU utilization charts during scheduled scans.

What Readers Will Learn in This Guide

This article provides a structured troubleshooting and optimization framework for reducing Wazuh FIM CPU usage.

You’ll learn how to:

• Identify whether FIM is truly causing the CPU issue
• Understand how the Syscheck engine consumes resources
• Locate inefficient monitoring configurations
• Exclude unnecessary files and directories
• Optimize scan frequency
• Reduce hashing overhead
• Tune real-time monitoring settings
• Minimize disk I/O and file traversal workloads
• Prevent future CPU spikes

By the end of this guide, you’ll be able to significantly reduce FIM-related resource consumption while maintaining strong file integrity monitoring coverage.

Understanding How Wazuh File Integrity Monitoring Works

Before optimizing CPU usage, it’s important to understand exactly what the FIM engine is doing behind the scenes.

Many administrators focus on CPU metrics without understanding the operations generating the workload.

Once you understand how Syscheck scans files, calculates hashes, and processes file events, the root causes of high CPU utilization become much easier to identify.

What FIM Monitors

Wazuh File Integrity Monitoring can track several types of system objects.

Files

Individual files can be monitored for:

• Content modifications
• Permission changes
• Ownership changes
• Timestamp changes
• Hash changes

Examples include:

• Configuration files
• Application binaries
• Scripts
• Security-sensitive documents

Directories

Directories can be recursively monitored to detect:

• New file creation
• File deletion
• File modifications
• Permission changes

Recursive directory monitoring is one of the largest contributors to CPU consumption when configured improperly.

Registry Keys (Windows)

On Windows systems, Wazuh can monitor registry locations for:

• New registry entries
• Deleted keys
• Modified values
• Security setting changes

Registry monitoring adds additional processing overhead but is often necessary for detecting persistence mechanisms used by malware.

Critical System Paths

Many organizations monitor critical operating system locations such as:

Linux:

• /etc
• /bin
• /usr/bin
• /usr/sbin

Windows:

• System32
• Program Files
• Security-related registry hives

Monitoring these locations helps detect unauthorized system modifications while maintaining a reasonable scope.

How Wazuh Detects Changes

The Syscheck engine uses multiple techniques to determine whether monitored files have changed.

Real-Time Monitoring

Real-time monitoring uses operating system notification APIs such as:

• inotify (Linux)
• FSEvents (macOS)
• Windows file system notifications

Instead of repeatedly scanning files, the operating system notifies Wazuh when changes occur.

Real-time monitoring is generally more efficient than frequent full scans, but can still become resource intensive in directories experiencing constant file activity.

Scheduled Scans

Scheduled scans periodically walk through monitored directories and compare current file states against the stored baseline.

During these scans, Wazuh must:

1. Enumerate files
2. Collect metadata
3. Calculate hashes
4. Compare results
5. Generate alerts

Large scans can consume significant CPU resources.

Checksum Verification

One of the most expensive operations performed by FIM is checksum generation.

Wazuh commonly calculates:

• MD5
• SHA1
• SHA256

Hashing requires reading file contents and performing cryptographic calculations.

The larger the file set, the greater the CPU cost.

Security expert guidance from notes that file integrity verification processes can become resource intensive when performed at large scale, making careful scope management essential.

Metadata Collection

In addition to hashes, Wazuh collects metadata such as:

• File size
• Ownership
• Permissions
• Modification timestamps
• Creation timestamps

Although metadata collection is less expensive than hashing, the cumulative impact across millions of files can still be significant.

Why FIM Is CPU Intensive by Nature

Some CPU usage is unavoidable because integrity monitoring requires continuous validation of system state.

Frequent File Hashing

Cryptographic hashing is computationally expensive.

Every time a monitored file is scanned, the agent may need to:

• Read the file
• Process its contents
• Calculate one or more hashes
• Compare results with stored values

This workload scales directly with file count and file size.

Large Directory Traversals

Recursive directory scans require the agent to walk every folder and subfolder.

A directory structure containing hundreds of thousands of files can generate substantial CPU activity during each scan cycle.

Monitoring High-Churn Locations

Some directories experience constant changes.

Examples include:

• Log directories
• Temporary folders
• Cache directories
• Application upload locations
• Container storage paths

Monitoring these areas often generates far more work than monitoring static system files.

This is one reason why our guide on How to Monitor Kubernetes Using Wazuh recommends carefully selecting monitored container paths rather than monitoring entire container file systems.

Processing Millions of File Events

In large enterprise environments, the number of file events can be enormous.

For every detected change, Wazuh must:

1. Capture the event
2. Validate the file
3. Gather metadata
4. Calculate hashes when required
5. Generate alerts
6. Forward event data

As event volume grows, CPU consumption rises proportionally.

Security researchers at consistently identify file modifications as a key indicator of compromise, which explains why organizations rely heavily on FIM despite its resource costs.

Common Symptoms of Wazuh Integrity Monitoring High CPU Usage

Identifying the symptoms early can help prevent resource exhaustion and performance degradation across your environment.

High CPU Usage on Wazuh Agents

The most obvious symptom is elevated CPU utilization on monitored endpoints.

You may observe:

• wazuh-agent processes consuming excessive CPU
• CPU spikes during scan intervals
• Increased load averages on Linux systems
• Reduced responsiveness on servers

This issue is especially common when:

• Monitoring too many files
• Scanning large directories
• Using aggressive scan frequencies

High CPU Usage on the Wazuh Manager

Although FIM workloads primarily execute on agents, managers can also experience increased CPU utilization.

This occurs when:

• Thousands of agents generate file events simultaneously
• Large numbers of integrity alerts are processed
• Rule evaluation workloads increase
• Indexing workloads grow

If manager-side CPU becomes problematic, you may also benefit from techniques discussed in Why Is Wazuh Using High CPU? Troubleshooting Guide.

Increased Scan Completion Times

As monitored file counts grow, scan duration often increases.

Warning signs include:

• Scans taking longer than expected
• Overlapping scan cycles
• Continuous scanning behavior
• Delayed baseline updates

Long-running scans often indicate that the monitored scope is too broad.

System Slowdowns During Scheduled Scans

Many administrators notice performance issues only during scan windows.

Typical symptoms include:

• Slower application response times
• Increased latency
• Higher system load
• Temporary performance degradation

These slowdowns frequently coincide with intensive file hashing operations.

Elevated Disk I/O Alongside CPU Spikes

CPU spikes rarely occur in isolation.

FIM must read files before hashing them, which increases disk activity.

Common indicators include:

• High read operations
• Increased disk queue lengths
• Elevated storage latency
• Simultaneous CPU and disk spikes

When CPU and disk utilization rise together, file hashing is often the primary culprit.

Delayed Alert Processing

Excessive FIM workloads can impact alert delivery timelines.

You may observe:

• Integrity alerts arriving late
• Backlogged event queues
• Delayed correlation rules
• Increased manager processing times

In severe cases, these delays can affect other monitoring functions as well.

Organizations experiencing alert pipeline congestion should also review Fix Wazuh Logcollector Dropped Messages, since excessive event generation can contribute to downstream processing bottlenecks.

Common Symptoms of Wazuh Integrity Monitoring High CPU Usage

When File Integrity Monitoring consumes excessive resources, the impact is rarely limited to a single process.

CPU spikes often trigger secondary performance issues that affect agents, managers, storage systems, and even alerting pipelines.

Recognizing these symptoms early can help administrators identify FIM-related bottlenecks before they become major operational problems.

High CPU Usage on Wazuh Agents

The most common symptom is elevated CPU utilization on endpoints running the Wazuh agent.

Because Syscheck performs file scans locally, the majority of FIM processing occurs directly on monitored systems rather than the manager.

Administrators may observe:

• Wazuh agent processes consistently consuming CPU
• Periodic CPU spikes during scan intervals
• Increased system load averages
• Reduced application responsiveness
• Slower login sessions or desktop performance

Linux administrators often notice the wazuh-syscheckd process near the top of resource utilization reports during active scans.

This issue becomes especially noticeable on servers that:

• Host large filesystems
• Generate constant file activity
• Store large log volumes
• Run with limited CPU resources

High CPU Usage on the Wazuh Manager

Although agents perform the actual file monitoring work, managers can also experience CPU increases when processing large volumes of integrity monitoring events.

Every file change detected by an agent must be:

1. Sent to the manager
2. Parsed
3. Evaluated against rules
4. Correlated with other events
5. Indexed for searching and reporting

As event volume grows, manager CPU utilization may increase substantially.

Common indicators include:

• Elevated manager load averages
• Increased rule processing times
• High OpenSearch utilization
• Delayed dashboard updates
• Slower query performance

Increased Scan Completion Times

One of the earliest warning signs is a noticeable increase in scan duration.

A scan that previously completed in a few minutes may begin taking significantly longer as file counts grow.

Common causes include:

• Expanded monitoring scope
• Large numbers of new files
• Increased hashing workloads
• Slower storage subsystems

Administrators may notice:

• Baseline scans running longer than expected
• Scheduled scans overlapping with subsequent scans
• Continuous scanning behavior
• Delayed completion messages in logs

Long scan times usually indicate that the monitored scope has become too large or inefficient.

System Slowdowns During Scheduled Scans

Many administrators first discover the problem through user complaints.

Applications that normally perform well may become sluggish whenever scheduled integrity scans begin.

Typical symptoms include:

• Slower application response times
• Increased latency
• Higher system load
• Delayed user interactions
• Reduced throughput

This occurs because Syscheck competes with business applications for CPU cycles, memory, and storage resources.

Servers with limited hardware resources are particularly vulnerable to these performance impacts.

Elevated Disk I/O Alongside CPU Spikes

High FIM CPU usage is frequently accompanied by increased disk activity.

Before a file can be hashed, Wazuh must read its contents from storage.

As a result, integrity scans generate both:

• CPU-intensive hashing operations
• Storage-intensive read operations

Common indicators include:

• Increased read throughput
• Elevated IOPS
• Storage latency spikes
• Longer disk queue lengths
• Simultaneous CPU and disk utilization increases

If both CPU and disk metrics rise together during scan windows, file hashing is often the root cause.

Delayed Alert Processing

As system resources become saturated, alert processing may begin falling behind.

This can create delays between:

• A file modification occurring
• The change being detected
• The alert reaching the manager
• The event appearing in dashboards

Warning signs include:

• Integrity alerts arriving late
• Backlogged event queues
• Delayed correlation rules
• Increased indexing latency
• Dashboard refresh delays

In larger deployments, excessive FIM activity can even contribute to ingestion bottlenecks.

If event processing delays are occurring, review Fix Wazuh Logcollector Dropped Messages for additional troubleshooting strategies.

How to Confirm FIM Is Causing the CPU Problem

Before modifying your configuration, it’s important to verify that File Integrity Monitoring is actually responsible for the resource spike.

Many administrators assume FIM is the culprit when the issue may instead involve:

• Log collection
• Active response
• OpenSearch indexing
• Dashboard services
• Third-party integrations

The following diagnostic steps can help isolate Syscheck-related CPU consumption.

Check Wazuh Agent Resource Consumption

The fastest way to verify a FIM issue is to inspect agent resource utilization directly.

Linux Commands

Several Linux utilities can quickly identify whether Syscheck is consuming CPU resources.

top

The top command provides a real-time view of running processes.

top

Look for:

• wazuh-syscheckd
• wazuh-agentd
• wazuh-modulesd

High CPU percentages associated with wazuh-syscheckd strongly suggest FIM activity.

htop

Many administrators prefer htop because it provides a more user-friendly interface.

htop

Sort processes by CPU utilization and observe whether Syscheck rises to the top during scan periods.

ps aux | grep wazuh

You can also identify active Wazuh processes using:

ps aux | grep wazuh

This command helps verify which Wazuh components are currently running and consuming resources.

Windows Monitoring Tools

Windows administrators can use built-in monitoring utilities to identify resource-intensive Wazuh processes.

Task Manager

Open Task Manager and review:

• CPU utilization
• Process activity
• Resource trends

Look for the Wazuh Agent service consuming significant CPU.

Resource Monitor

Resource Monitor provides additional visibility into:

• CPU activity
• Disk reads
• File operations
• Process-level resource usage

This tool is especially useful when CPU spikes coincide with heavy disk activity.

Performance Monitor

Performance Monitor allows long-term tracking of:

• Processor utilization
• Process CPU percentages
• Disk throughput
• Memory usage

Historical performance data can reveal recurring spikes that align with scheduled Syscheck scans.

Review Wazuh Logs

Wazuh logs provide valuable evidence when diagnosing FIM-related performance issues.

Agent Logs

The primary log file is:

/var/ossec/logs/ossec.log

This file records Syscheck activity, scan status messages, and operational events.

Common FIM-Related Log Entries

Typical Syscheck messages include:

Starting syscheck scan.

Ending syscheck scan.

Real-time file monitoring started.

Frequent scanning messages combined with high CPU utilization often indicate an aggressive monitoring configuration.

Identify Syscheck Activity

The Syscheck daemon is responsible for file integrity monitoring operations.

Understanding the syscheckd Process

The wazuh-syscheckd process performs:

• File enumeration
• Metadata collection
• Checksum generation
• Baseline comparisons
• Event generation

If this process consistently consumes CPU, FIM is almost certainly involved.

Recognizing Scan Start and Completion Messages

Log files typically contain messages indicating when scans begin and end.

Examples include:

Starting syscheck scan.

Ending syscheck scan.

Comparing these timestamps against CPU monitoring data can quickly confirm whether scan activity aligns with resource spikes.

Monitor CPU Usage During Scheduled Scans

Many FIM issues occur only during scheduled scan windows.

To verify this:

1. Identify the configured scan interval.
2. Monitor CPU utilization before the scan begins.
3. Observe CPU activity during the scan.
4. Compare utilization after the scan completes.

Correlating Scan Times With CPU Spikes

If CPU usage rises immediately after:

Starting syscheck scan.

and returns to normal after:

Ending syscheck scan.

then File Integrity Monitoring is almost certainly the primary source of the problem.

Establishing this correlation before making configuration changes helps ensure you’re optimizing the correct component.

Most Common Causes of Wazuh FIM High CPU Usage

Once you’ve confirmed Syscheck is responsible, the next step is identifying exactly what is driving the workload.

In most environments, high CPU utilization can be traced to one or more common configuration mistakes.

Monitoring Too Many Files

The most frequent cause of FIM-related CPU issues is excessive monitoring scope.

Many administrators initially configure Syscheck to watch far more files than necessary.

Excessive Directory Coverage

Every monitored directory increases:

• Scan duration
• Metadata collection workload
• Hashing operations
• Event processing volume

The broader the monitoring scope, the more CPU resources Syscheck requires.

Entire Filesystem Monitoring Mistakes

A common mistake is monitoring entire filesystems.

Examples include:

<directories realtime="yes">/</directories>

or

<directories realtime="yes">C:\</directories>

While comprehensive, this approach dramatically increases resource consumption and rarely improves security visibility.

Security experts generally recommend monitoring only high-value locations rather than the entire operating system.

Monitoring High-Change Directories

Some directories generate continuous file activity.

Monitoring these locations often creates overwhelming numbers of events.

Examples

Browser Caches

Browser cache directories constantly create, modify, and delete files.

Examples include:

• Chrome cache
• Edge cache
• Firefox cache

These locations rarely provide meaningful security insights.

Temporary Folders

Temporary directories generate large numbers of short-lived files.

Examples:

• /tmp
• /var/tmp
• Windows Temp

Monitoring them can dramatically increase event volume.

Application Log Directories

Busy applications may update log files every few seconds.

Constant log modifications can trigger continuous FIM activity.

Build Artifact Directories

CI/CD systems frequently create and replace thousands of files during builds.

Monitoring build output folders often generates excessive resource consumption with limited security value.

Frequent Scheduled Scans

Scan frequency has a direct impact on CPU utilization.

Aggressive Scan Intervals

Some environments schedule scans too frequently.

Examples:

• Every 5 minutes
• Every 10 minutes
• Every 15 minutes

If a scan takes several minutes to complete, frequent scheduling can create continuous resource pressure.

Overlapping Scan Jobs

Overlapping scans occur when a new scan begins before the previous one finishes.

This situation can lead to:

• Sustained CPU utilization
• Increased disk activity
• Event backlogs
• Delayed alert processing

Real-Time Monitoring on Busy Servers

Real-time monitoring is extremely useful but can become expensive on systems with constant file activity.

Database Servers

Database systems frequently update:

• Data files
• Transaction logs
• Temporary files

Monitoring these locations can generate enormous event volumes.

Application Servers

Application servers often:

• Write logs continuously
• Generate cache files
• Update runtime data

These changes can trigger persistent monitoring activity.

CI/CD Build Systems

Build pipelines continuously create, modify, and delete files.

Real-time monitoring on build servers is a common source of excessive CPU consumption.

Excessive Checksum Calculations

Checksum generation is one of the most CPU-intensive FIM operations.

MD5

Although relatively lightweight, MD5 still requires processing every monitored file.

SHA1

SHA1 calculations consume additional CPU resources compared to simple metadata checks.

SHA256

SHA256 provides stronger integrity validation but generally requires more processing than MD5 or SHA1.

When monitoring hundreds of thousands of files, hashing overhead becomes significant.

Monitoring Large Files

Large files require more time to read and hash.

Database Files

Database files may be several gigabytes in size.

Hashing them repeatedly can create substantial CPU and storage workloads.

VM Images

Virtual machine images are another common source of excessive scan durations.

Examples include:

• VMDK files
• VHDX files
• QCOW2 images

Backup Archives

Large backup archives often provide little integrity-monitoring value while generating significant hashing overhead.

Examples include:

• ZIP archives
• TAR files
• Backup snapshots

Excessive Number of Agents

As deployments grow, aggregate FIM workloads increase dramatically.

Scaling Challenges in Large Deployments

A configuration that works perfectly for:

• 50 agents

may become problematic at:

• 5,000 agents

Large deployments generate more:

• File events
• Alerts
• Correlation workloads
• Indexing operations

This increased volume can affect both agents and managers.

Hardware Resource Constraints

In some cases, the FIM configuration is reasonable but the underlying infrastructure lacks sufficient resources.

Limited CPU Cores

Servers with small CPU allocations may struggle to process scans efficiently.

Common examples include:

• Single-vCPU virtual machines
• Small cloud instances
• Lightweight lab environments

Virtualized Environments

Virtual machines frequently compete for resources with neighboring workloads.

CPU contention can amplify the performance impact of FIM scans.

Resource Contention

When multiple resource-intensive applications share the same host, Syscheck may appear more expensive than it actually is.

Examples include:

• Databases
• Backup software
• Endpoint security tools
• Monitoring agents

Understanding these root causes is essential before applying optimization changes, because reducing CPU usage effectively requires targeting the specific workload generating the overhead.

Fix 1: Reduce the Number of Monitored Directories

One of the fastest and most effective ways to reduce Wazuh FIM CPU consumption is to decrease the number of directories being monitored.

Many deployments begin with overly broad monitoring configurations that include thousands or even millions of files that provide little security value.

By narrowing the monitoring scope to security-relevant locations, administrators can significantly reduce file traversal, hashing operations, and event generation.

Review Existing Syscheck Configuration

Start by reviewing your current Syscheck configuration in the agent’s ossec.conf file.

Typical locations include:

Linux

<syscheck>
  ...
</syscheck>

Windows

<syscheck>
  ...
</syscheck>

Look specifically for:

• Large directory trees
• Recursive monitoring rules
• Entire filesystem monitoring
• Directories containing application data
• Log storage locations
• Temporary file locations

Many high-CPU environments contain monitoring entries that were added during initial deployment and never revisited.

For guidance on validating your configuration syntax, see How to Fix ossec.conf Syntax Errors in Wazuh Agents.

Remove Non-Critical Directories

Not every file on a system needs integrity monitoring.

A common mistake is attempting to monitor:

• Entire operating system partitions
• User home directories
• Cache folders
• Temporary storage locations
• Application data directories
• Backup repositories

Ask the following question for each monitored directory:

“Would a change in this location represent a meaningful security event?”

If the answer is no, consider removing it from FIM monitoring.

Examples of directories that are often unnecessarily monitored include:

Linux

• /tmp
• /var/tmp
• /var/cache
• /home
• /mnt/backups

Windows

• Temporary directories
• Browser caches
• Download folders
• Software distribution caches

Reducing monitoring scope directly reduces:

• File enumeration workloads
• Metadata collection
• Checksum generation
• Alert processing volume

Focus on Security-Relevant Locations

Security-focused monitoring typically delivers better protection while consuming far fewer resources.

Examples of high-value Linux locations include:

• /etc
• /usr/bin
• /usr/sbin
• /bin
• /sbin

These locations contain:

• System configurations
• Administrative utilities
• Core operating system binaries

Changes in these areas are often far more important than modifications within temporary storage directories.

Example

<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>

This configuration provides visibility into critical operating system files while avoiding unnecessary monitoring of less important locations.

The official Wazuh documentation recommends focusing monitoring efforts on sensitive files and system configurations rather than attempting to monitor every file on the system.

Verify Monitoring Coverage After Changes

After removing directories, verify that your security objectives are still being met.

Recommended validation steps include:

1. Modify a monitored configuration file.
2. Confirm that Wazuh generates an alert.
3. Review recent Syscheck events.
4. Verify that critical operating system files remain covered.
5. Confirm compliance requirements are still satisfied.

This validation process helps ensure that CPU optimization does not create visibility gaps.

You can also use techniques from How to Test Wazuh Rules to verify that integrity monitoring alerts continue functioning correctly after configuration changes.

Fix 2: Exclude High-Churn Directories

Even when monitoring scope is reasonable, CPU usage can remain high if Wazuh is tracking directories that change constantly.

These locations generate enormous numbers of file events and often contribute little meaningful security information.

Excluding them can dramatically reduce both CPU utilization and alert noise.

Common Directories to Exclude

The exact exclusions will vary by environment, but certain locations are frequent sources of unnecessary Syscheck activity.

Linux

/tmp

The /tmp directory is one of the most common causes of excessive FIM workloads.

Applications continuously:

• Create temporary files
• Delete temporary files
• Modify temporary data

Monitoring this directory often produces large event volumes with minimal security value.

/var/tmp

Like /tmp, this location stores temporary application data.

Frequent file churn can generate significant CPU overhead.

/var/cache

Many Linux applications write cached content to this directory.

Examples include:

• Package managers
• Browsers
• Software repositories

These files change frequently and rarely require integrity monitoring.

Windows

C:\Windows\Temp

Windows and installed applications constantly write temporary data here.

Monitoring this directory can generate continuous event streams.

C:\Users*\AppData\Local\Temp

User-level temporary folders are another common source of unnecessary file events.

Applications frequently create and remove files in these locations throughout the day.

Other commonly excluded Windows locations include:

• Browser caches
• Software update caches
• Application cache folders

Configuring Ignore Rules

Wazuh allows administrators to exclude specific paths using ignore rules.

These exclusions prevent Syscheck from scanning or monitoring selected directories.

Example

<ignore>/tmp</ignore>

Multiple exclusions can be configured as needed.

Examples:

<ignore>/tmp</ignore>
<ignore>/var/tmp</ignore>
<ignore>/var/cache</ignore>

Windows examples:

<ignore>C:\Windows\Temp</ignore>

When creating ignore rules, focus on locations that:

• Change frequently
• Generate excessive events
• Contain non-critical files
• Produce little security value

Be careful not to exclude directories that contain:

• Security-sensitive configurations
• Critical application files
• System binaries
• Compliance-related assets

Measuring CPU Improvements

After implementing exclusions, measure the impact before making additional changes.

Monitor:

• CPU utilization
• Scan duration
• Disk I/O
• Alert volume
• Syscheck event counts

Many organizations see substantial improvements simply by excluding temporary and cache directories.

Compare:

Before

• CPU usage during scans
• Number of monitored files
• Event volume

After

• CPU usage during scans
• Scan completion times
• Alert generation rates

This data-driven approach makes it easier to identify which exclusions provide the greatest benefit.

Fix 3: Increase the Scan Interval

Another highly effective optimization is reducing how often Syscheck performs scheduled scans.

Many environments run integrity scans far more frequently than necessary.

Increasing the scan interval reduces the number of times Wazuh must:

• Traverse directories
• Read files
• Calculate hashes
• Compare baselines
• Generate alerts

As a result, CPU consumption often drops significantly.

Understanding Scan Frequency

The Syscheck frequency setting controls how often scheduled scans occur.

For example:

<frequency>3600</frequency>

This configuration instructs Wazuh to perform a scan every hour.

While frequent scanning may appear beneficial, it also increases resource consumption.

In many environments, hourly scans provide little additional value compared to scans performed every several hours.

Why Frequent Scans Create CPU Pressure

Every scheduled scan requires Wazuh to repeat many expensive operations.

These include:

• Directory traversal
• Metadata collection
• Hash calculations
• Change detection
• Event generation

If scans occur too frequently, the system may spend a significant portion of its time continuously processing integrity checks.

Problems become especially severe when:

• Large filesystems are monitored
• File counts exceed hundreds of thousands
• Multiple checksum algorithms are enabled
• Scan durations approach the scan interval

In extreme cases, one scan may still be running when the next scan begins.

Recommended Scan Intervals

The ideal frequency depends on the system’s purpose and risk profile.

These recommendations strike a balance between:

• Security visibility
• Resource consumption
• Operational performance

Organizations that rely heavily on real-time monitoring can often use even longer scheduled scan intervals because file changes are already being captured immediately.

Example Configuration

The following example configures a 12-hour scan interval:

<frequency>43200</frequency>

Because the value is specified in seconds:

• 3,600 = 1 hour
• 21,600 = 6 hours
• 43,200 = 12 hours
• 86,400 = 24 hours

A 12-hour schedule is often sufficient for most production systems while significantly reducing CPU overhead compared to hourly scans.

After adjusting the interval, continue monitoring:

• CPU utilization
• Scan duration
• Alert timeliness
• Security coverage

The goal is to find the lowest scan frequency that still satisfies your organization’s operational and compliance requirements.

For environments that require aggressive monitoring but suffer from resource constraints, combining longer scan intervals with carefully tuned real-time monitoring typically provides the best balance between performance and visibility.

Fix 4: Disable Unnecessary Checksum Algorithms

Checksum generation is one of the most CPU-intensive operations performed by the Wazuh Syscheck module.

While cryptographic hashes provide strong integrity verification, calculating multiple hashes for every monitored file can significantly increase CPU utilization, especially on systems containing hundreds of thousands of files.

Reducing unnecessary hash calculations is often one of the easiest ways to lower FIM-related resource consumption.

How Checksum Calculations Impact CPU Usage

Whenever Syscheck scans a file, it may calculate several different hashes depending on the configuration.

Commonly used algorithms include:

• MD5
• SHA1
• SHA256

For every monitored file, Wazuh must:

1. Read the file from disk
2. Process its contents
3. Calculate one or more checksums
4. Compare the results against stored values

The larger the file and the more algorithms enabled, the greater the CPU cost.

For example, monitoring 500,000 files while calculating three separate hashes requires substantially more processing than calculating a single hash.

This is particularly noticeable during:

• Initial baseline scans
• Full scheduled scans
• Large filesystem traversals
• Systems with slower storage

Determining Which Hashes You Actually Need

Many deployments continue using default hash configurations even when multiple algorithms are unnecessary.

Ask the following questions:

• Are specific compliance frameworks requiring a particular hash?
• Are integrity reports consuming multiple hash values?
• Are existing workflows dependent on MD5, SHA1, and SHA256 simultaneously?

In many environments:

• SHA256 alone is sufficient
• MD5 may be retained for legacy compatibility
• SHA1 may provide little additional value

The exact decision depends on:

• Compliance requirements
• Internal security policies
• Reporting needs
• Existing integrations

If no process actively uses multiple hash algorithms, disabling redundant calculations can significantly reduce CPU overhead.

Optimized Configuration Example

Many environments can simplify checksum calculations by focusing on a single modern hash algorithm.

Example:

<check_sum>yes</check_sum>
<sha256sum>yes</sha256sum>
<md5sum>no</md5sum>
<sha1sum>no</sha1sum>

This configuration reduces the amount of work performed during each scan while still maintaining strong integrity validation.

Before implementing changes, verify compatibility with:

• Compliance requirements
• Security policies
• Reporting workflows
• Third-party integrations

Security vs Performance Trade-Offs

Disabling checksum algorithms introduces a trade-off between visibility and efficiency.

Potential performance benefits include:

• Lower CPU utilization
• Faster scan completion
• Reduced disk activity
• Smaller resource footprint

Potential drawbacks include:

• Reduced compatibility with legacy processes
• Fewer hash values available for investigations
• Possible compliance implications

Security experts generally recommend prioritizing strong modern hashing rather than calculating multiple redundant hashes simply because they are available.

For most organizations, carefully selecting one or two necessary algorithms provides an effective balance between security and performance.

Fix 5: Fine-Tune Real-Time Monitoring

Real-time monitoring is one of Wazuh’s most powerful FIM capabilities, but it can also become a major source of CPU consumption when applied indiscriminately.

The goal is not to disable real-time monitoring entirely, but rather to use it strategically where it provides the greatest security value.

When Real-Time Monitoring Makes Sense

Real-time monitoring is ideal for files and directories where immediate visibility is important.

Examples include:

• Critical system configurations
• Authentication-related files
• Security tool configurations
• Administrative scripts
• Sensitive application settings

Common Linux examples:

• /etc/passwd
• /etc/shadow
• /etc/sudoers
• /etc/ssh

Common Windows examples:

• Security-related registry keys
• Administrative scripts
• Critical application configurations

These locations change infrequently, making real-time monitoring efficient while providing high-value security coverage.

When Scheduled Scanning Is Better

Not every directory requires immediate change detection.

Scheduled scanning is often sufficient for:

• Static application files
• Software installation directories
• Compliance verification
• Long-term integrity monitoring
• Large file repositories

Examples include:

• Documentation repositories
• Software archives
• Historical log storage
• Backup locations

Using scheduled scans instead of real-time monitoring can dramatically reduce event volume on busy systems.

Reducing Real-Time Scope

One of the most common causes of FIM-related CPU issues is enabling real-time monitoring on large directory trees.

For example:

<directories realtime="yes">/var</directories>

This configuration may generate enormous numbers of file events.

A more efficient approach is to limit real-time monitoring to high-value locations only.

Examples:

<directories realtime="yes">/etc</directories>

<directories realtime="yes">/opt/security-config</directories>

By reducing the scope, Wazuh processes fewer events while still monitoring critical assets.

Example Configuration Adjustments

Overly broad configuration:

<directories realtime="yes">/var</directories>
<directories realtime="yes">/home</directories>

Optimized configuration:

<directories realtime="yes">/etc</directories>
<directories>/var/www</directories>

In this example:

• Critical configuration files receive immediate monitoring.
• Less sensitive content is checked during scheduled scans.
• Event volume is significantly reduced.

This hybrid approach is commonly recommended by experienced Wazuh administrators because it balances security visibility with system performance.

If you are monitoring containerized workloads, consider applying similar principles from How to Monitor Kubernetes Using Wazuh, where carefully selecting monitored paths is critical for maintaining performance.

Fix 6: Limit Monitoring of Large Files

Large files are another frequent source of excessive CPU consumption.

Even when the number of monitored files is relatively small, a handful of very large files can dramatically increase scan duration and resource utilization.

Reducing or eliminating monitoring of these files often produces immediate performance improvements.

Why Large Files Consume Significant CPU Resources

Before Wazuh can verify file integrity, it must read the file and calculate the configured checksums.

The larger the file, the more data must be processed.

Examples include:

• Multi-gigabyte database files
• Virtual machine images
• Backup archives
• Application data stores

Scanning these files requires:

• Significant disk reads
• Increased memory usage
• Additional CPU cycles for hashing

A 10 GB file requires far more processing than a 10 KB configuration file, yet may provide relatively little security value in a FIM context.

Configure Maximum File Size Limits

Wazuh allows administrators to limit the size of files that are monitored.

This prevents extremely large files from consuming excessive resources during scans.

A typical approach is to monitor:

• Configuration files
• Scripts
• Executables
• Security-sensitive documents

while excluding files above a defined size threshold.

The appropriate threshold depends on:

• Available hardware
• File inventory
• Compliance requirements
• Security objectives

Many organizations find that excluding very large files significantly reduces both CPU utilization and scan duration.

Exclude Archive and Database Files

Certain file types are particularly expensive to monitor and often provide limited integrity-monitoring value.

Examples include:

.zip Files

Compressed archives can be extremely large and frequently change during software distribution processes.

.tar Files

Backup and deployment systems often generate large TAR archives that require substantial hashing effort.

.bak Files

Backup files are commonly recreated or updated and rarely need continuous integrity monitoring.

.vmdk Files

Virtual machine disk images can consume enormous amounts of CPU during hashing operations.

Other virtualization formats may create similar issues, including:

• VHD
• VHDX
• QCOW2

Database Data Files

Database storage files are among the worst candidates for FIM monitoring.

Examples include:

• MySQL data files
• PostgreSQL data files
• SQL Server database files
• Oracle data files

These files:

• Change constantly
• Are often extremely large
• Generate excessive hashing workloads

Monitoring transaction logs and database storage locations can overwhelm Syscheck without providing meaningful security insight.

Instead, focus monitoring efforts on:

• Database configuration files
• Access control settings
• Administrative scripts
• Critical application configurations

This approach delivers stronger security value while dramatically reducing CPU consumption.

As a general rule, if a file is measured in gigabytes and changes continuously, it is usually a poor candidate for File Integrity Monitoring.

Limiting these files often results in some of the largest CPU reductions available when tuning Wazuh FIM performance.

Fix 7: Optimize Windows FIM Monitoring

Windows systems present unique File Integrity Monitoring challenges.

Compared to many Linux servers, Windows endpoints often generate significantly more file activity due to user applications, operating system updates, browser activity, and registry modifications.

A FIM configuration that works well on Linux may create excessive CPU consumption on Windows if monitoring scope is not carefully controlled.

Optimizing Windows-specific monitoring can substantially reduce Syscheck overhead while maintaining strong security visibility.

Reduce Registry Monitoring Scope

Registry monitoring is one of the most valuable Windows security features available in Wazuh.

However, monitoring too many registry locations can generate a large number of integrity events.

Focus on monitoring security-relevant areas such as:

• Startup locations
• Service configurations
• Security settings
• User account settings
• Authentication-related configurations

Examples include:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

HKEY_LOCAL_MACHINE\SYSTEM

HKEY_LOCAL_MACHINE\SECURITY

Avoid monitoring large sections of the registry without a specific security objective.

Overly broad registry monitoring can result in:

• Excessive event generation
• Increased CPU utilization
• Alert fatigue
• Longer scan durations

For organizations concerned primarily with persistence detection, focusing on known startup and autorun locations typically provides the greatest value.

Exclude Temporary System Locations

Windows continuously creates temporary files for:

• Software installations
• Updates
• Browsers
• Application execution
• User sessions

Monitoring these locations often creates substantial CPU overhead without meaningful security benefits.

Common candidates for exclusion include:

C:\Windows\Temp

C:\Temp

C:\ProgramData\Package Cache

These directories experience frequent file creation and deletion, causing Syscheck to process large numbers of low-value events.

Adding exclusions can significantly reduce monitoring noise and CPU consumption.

Avoid Monitoring User Cache Directories

User profile directories often contain caches that change constantly throughout the day.

Examples include:

• Browser caches
• Application caches
• Thumbnail caches
• Update caches
• Synchronization caches

Common locations include:

C:\Users\*\AppData\Local

C:\Users\*\AppData\Roaming

Unless there is a specific compliance or security requirement, these locations are usually poor candidates for integrity monitoring.

Monitoring them frequently leads to:

• High event volume
• Excessive file hashing
• Increased CPU usage
• Larger alert queues

Instead, focus monitoring efforts on configuration files, startup locations, and administrative scripts.

Windows-Specific Performance Considerations

Windows environments often introduce additional factors that influence FIM performance.

Examples include:

• Frequent Windows Updates
• Endpoint security software
• Software deployment tools
• Active Directory policy updates
• User profile activity

These activities can generate large bursts of file changes that temporarily increase CPU consumption.

Performance tuning recommendations include:

• Narrow monitoring scope
• Exclude temporary paths
• Limit registry coverage
• Increase scan intervals where appropriate
• Monitor resource usage during update windows

If Windows agents are generating excessive event volumes, you may also see downstream effects on the manager.

In those cases, review Fix Wazuh Logcollector Dropped Messages and Why Is Wazuh Using High CPU? Troubleshooting Guide for additional optimization strategies.

Fix 8: Optimize Linux FIM Monitoring

Linux systems generally provide more predictable FIM performance than Windows, but improper monitoring configurations can still generate significant CPU overhead.

Most Linux-related FIM issues stem from monitoring too many files, tracking high-churn directories, or scanning container storage locations.

Focus on Security-Critical Paths

The most effective Linux FIM deployments concentrate on directories that are most likely to indicate malicious activity or unauthorized administrative changes.

Common examples include:

/etc

/usr/bin

/usr/sbin

/bin

/sbin

These locations contain:

• System configurations
• Executable binaries
• Administrative utilities
• Authentication settings

Changes in these directories are often high-value security events.

By focusing on these locations, administrators can reduce CPU usage while maintaining meaningful visibility into system integrity.

A typical configuration might look like:

<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>

This approach is generally more efficient than monitoring entire filesystems.

Exclude Log Rotation Directories

Log directories can generate substantial file activity.

Examples include:

/var/log

/var/log/archive

/var/log/old

Many Linux systems rotate logs daily or even hourly.

During rotation, files may be:

• Renamed
• Archived
• Compressed
• Deleted
• Recreated

These operations can trigger large numbers of Syscheck events.

If log integrity monitoring is required, consider monitoring only specific security-sensitive logs rather than the entire log hierarchy.

You can also review How to Monitor Failed SSH Login Attempts Using Wazuh and How to Monitor Apache Logs with Wazuh for more efficient methods of tracking log-based security events without relying solely on FIM.

Avoid Monitoring Container Runtime Directories

Containerized environments are one of the most common sources of excessive FIM workloads.

Containers create and modify files continuously, often at a rate far higher than traditional servers.

Examples

Docker Overlay Storage

Docker commonly stores container filesystem data in locations such as:

/var/lib/docker

Specifically:

/var/lib/docker/overlay2

These directories experience constant file changes as containers start, stop, and update.

Monitoring them can generate enormous event volumes.

Kubernetes Ephemeral Storage

Kubernetes workloads frequently create temporary files and ephemeral storage volumes.

Examples include:

/var/lib/kubelet

/var/lib/containerd

These directories often contain:

• Temporary container filesystems
• Runtime metadata
• Pod storage
• Overlay filesystems

Monitoring them usually results in excessive CPU consumption with limited security benefit.

Organizations running Kubernetes should instead focus on:

• Host operating system files
• Kubernetes configuration files
• Security-sensitive manifests
• Administrative scripts

For additional container-specific guidance, see How to Monitor Kubernetes Using Wazuh.

Fix 9: Tune Wazuh Manager Performance

Even after optimizing agents, manager-side bottlenecks can contribute to overall FIM performance problems.

Large deployments may generate millions of file integrity events, creating substantial processing workloads for the Wazuh manager.

Manager tuning helps ensure that integrity events are processed efficiently without introducing additional CPU pressure.

Reduce Event Backlogs

Event backlogs occur when agents generate data faster than the manager can process it.

Symptoms include:

• Delayed alerts
• Increased queue sizes
• Elevated manager CPU utilization
• Slow dashboard updates

Common causes include:

• Excessive FIM scope
• Aggressive scan schedules
• Large numbers of monitored agents
• Insufficient manager resources

Reducing unnecessary file events at the source is usually the most effective way to eliminate backlogs.

Verify Queue Health

Wazuh relies on internal queues to process incoming events.

Administrators should periodically monitor queue health to identify bottlenecks before they affect alert processing.

Warning signs include:

• Growing queue depths
• Persistent queue saturation
• Delayed event handling
• Increased processing latency

If queues remain consistently busy, excessive FIM activity may be overwhelming the manager.

Monitoring queue health should be part of every routine performance review.

Monitor Manager CPU Utilization

Regular manager monitoring helps identify scaling issues before they impact production environments.

Useful metrics include:

• CPU utilization
• Load averages
• Memory consumption
• Event processing rates
• OpenSearch indexing activity

Useful tools include:

Linux

top

htop

sar

Monitoring trends over time often reveals whether FIM workloads are steadily increasing as the environment grows.

If manager CPU usage remains elevated even after agent optimization, additional infrastructure tuning may be required.

Scale Hardware Resources When Necessary

At some point, optimization alone may no longer be sufficient.

Large environments often require additional resources to handle growing event volumes.

Potential upgrades include:

• Additional CPU cores
• Faster storage
• Increased memory
• Dedicated manager nodes
• Clustered architectures

Signs that scaling may be necessary include:

• Persistent CPU saturation
• High queue utilization
• Delayed alert processing
• Increasing ingestion latency
• Growth in monitored endpoints

Organizations operating large deployments should also review How to Build a Wazuh Indexer Cluster and How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes because manager performance issues frequently overlap with indexing and storage bottlenecks.

The best results typically come from combining agent-side optimizations with appropriately sized manager infrastructure.

Reducing unnecessary events lowers resource consumption, while properly scaled hardware ensures that legitimate integrity monitoring data can be processed efficiently as the environment grows.

Fix 10: Upgrade to Newer Wazuh Versions

If you’ve optimized your FIM configuration and are still experiencing excessive CPU utilization, it may be worth evaluating your Wazuh version.

Older releases can contain performance inefficiencies, resource management issues, and Syscheck-related bugs that have already been addressed in newer versions.

Upgrading won’t solve every CPU problem, but it can eliminate known issues while providing access to performance improvements introduced by the Wazuh development team.

Performance Improvements in Recent Releases

Wazuh continuously improves the efficiency of core components, including Syscheck.

Over time, performance enhancements may include:

• More efficient file scanning
• Improved event processing
• Better memory management
• Reduced resource overhead
• Enhanced scalability for large environments

Organizations running older versions may be missing years of optimizations.

Before troubleshooting complex CPU issues, verify whether the environment is operating on a supported and reasonably current release.

For release-specific improvements, review the official [OUTBOUND LINK: Wazuh Release Notes].

Bug Fixes Affecting Syscheck

Not all CPU issues are caused by configuration mistakes.

In some cases, excessive resource consumption may stem from:

• Software defects
• Event processing bugs
• Infinite scanning loops
• Real-time monitoring edge cases
• Platform-specific issues

Checking release notes and known issue trackers can help determine whether a particular problem has already been resolved.

Common indicators of a version-related issue include:

• CPU spikes without obvious configuration problems
• Sudden resource increases after upgrades
• Unexpected scanning behavior
• Repeated Syscheck errors in logs

If your deployment recently underwent a version change, you may also find How to Stop the Infinite Wazuh Login Loop After a Version Upgrade and How to Clear Stuck Migration Indices in Wazuh Dashboard useful when troubleshooting upgrade-related side effects.

Safe Upgrade Practices

Upgrading production security infrastructure should always follow a controlled process.

Recommended practices include:

1. Review release notes.
2. Verify version compatibility.
3. Back up critical configurations.
4. Test upgrades in a non-production environment.
5. Upgrade a small group of systems first.
6. Monitor resource utilization after deployment.

Pay particular attention to:

• Syscheck configuration changes
• New default settings
• Deprecated options
• Agent-manager compatibility requirements

For agent-side upgrades, see How to Upgrade a Wazuh Agent.

A phased rollout significantly reduces operational risk while allowing you to verify that CPU utilization improves as expected.

Example Optimized Syscheck Configuration

The following examples illustrate the principles discussed throughout this guide.

These configurations are not universal templates, but they provide a strong starting point for most environments.

Linux Example

<syscheck>
    <!-- optimized configuration -->

    <frequency>43200</frequency>

    <directories realtime="yes" check_all="yes">
        /etc
    </directories>

    <directories check_all="yes">
        /usr/bin,/usr/sbin
    </directories>

    <ignore>/tmp</ignore>
    <ignore>/var/tmp</ignore>
    <ignore>/var/cache</ignore>

    <ignore>/var/lib/docker</ignore>
    <ignore>/var/lib/containerd</ignore>

    <skip_nfs>yes</skip_nfs>
</syscheck>

This configuration:

• Focuses on security-critical files
• Uses real-time monitoring selectively
• Excludes temporary directories
• Excludes container runtime storage
• Uses a moderate scan frequency

Windows Example

<syscheck>
    <!-- optimized configuration -->

    <frequency>43200</frequency>

    <directories realtime="yes" check_all="yes">
        C:\Windows\System32
    </directories>

    <ignore>C:\Windows\Temp</ignore>
    <ignore>C:\Users\*\AppData\Local\Temp</ignore>

    <windows_registry>
        HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
    </windows_registry>
</syscheck>

This configuration:

• Prioritizes critical operating system files
• Limits registry monitoring scope
• Excludes temporary file locations
• Reduces unnecessary event generation

Always validate optimized configurations in a test environment before deploying them broadly.

How to Measure Improvement After Applying Changes

Optimization efforts should be measured rather than assumed.

Without baseline data, it can be difficult to determine whether a configuration change actually improved performance or simply shifted resource consumption elsewhere.

The following process helps quantify the effectiveness of your tuning efforts.

Establish a CPU Baseline

Before making changes, record current resource utilization.

Capture:

• Average CPU usage
• Peak CPU usage
• Scan duration
• Disk I/O metrics
• Event volume
• Alert generation rates

Useful tools include:

Linux

top

htop

sar

Windows

• Task Manager
• Resource Monitor
• Performance Monitor

A baseline provides an objective reference point for evaluating future improvements.

Monitor Before-and-After Metrics

After applying changes, compare the same metrics collected during the baseline phase.

Focus on:

• CPU utilization
• Scan completion times
• Disk throughput
• Event volumes
• Queue activity

A successful optimization should generally produce:

• Lower CPU consumption
• Faster scans
• Reduced event volume
• Improved system responsiveness

Documenting these improvements can also help justify future tuning efforts.

Track Scan Duration

Scan duration is one of the most useful indicators of FIM efficiency.

Monitor:

• Scan start times
• Scan completion times
• Total scan duration
• Frequency of overlapping scans

Many administrators discover that reducing monitoring scope decreases scan times dramatically.

For example:

Tracking these metrics over time helps identify new performance issues before they become severe.

Review Log Activity

The Wazuh log file provides useful insight into Syscheck behavior.

Review:

/var/ossec/logs/ossec.log

Look for:

• Scan start messages
• Scan completion messages
• Error conditions
• Warning messages
• Unusually frequent scan activity

A reduction in repetitive Syscheck activity often indicates that tuning efforts are working as intended.

Validate Security Coverage Remains Adequate

Performance improvements are valuable only if security visibility remains intact.

After implementing changes:

1. Modify a monitored file.
2. Confirm that Wazuh detects the change.
3. Verify alert generation.
4. Review compliance requirements.
5. Validate critical system paths remain covered.

Testing ensures that CPU reductions have not created monitoring blind spots.

You can use techniques from How to Test Wazuh Rules to verify that detection logic continues functioning properly after optimization.

Best Practices to Prevent Future FIM CPU Problems

Once CPU usage is under control, the next goal is preventing the problem from returning.

FIM environments naturally evolve over time as applications, directories, and infrastructure change.

Following these best practices can help maintain efficient long-term performance.

Monitor Only Security-Relevant Files

Every monitored file consumes resources.

Prioritize:

• Configuration files
• Administrative scripts
• Security settings
• Critical executables
• Authentication-related files

Avoid monitoring files simply because they exist.

Monitoring should always serve a specific security objective.

Regularly Review FIM Scope

Monitoring requirements change over time.

At least quarterly, review:

• Monitored directories
• Registry paths
• Exclusion rules
• Scan frequency settings

Remove entries that no longer provide security value.

Periodic reviews prevent monitoring scope from growing uncontrollably.

Exclude Temporary and Dynamic Directories

Temporary directories are among the most common causes of excessive FIM workloads.

Examples include:

Linux

• /tmp
• /var/tmp
• /var/cache

Windows

• C:\Windows\Temp
• User temp folders
• Browser caches

Excluding these locations reduces both CPU utilization and alert noise.

Use Real-Time Monitoring Selectively

Real-time monitoring should be reserved for:

• Critical configurations
• Security-sensitive files
• High-value assets

Avoid enabling real-time monitoring across large directory trees unless there is a clear operational requirement.

A targeted approach typically provides better performance and more meaningful alerts.

Schedule Scans During Off-Peak Hours

If scheduled scans generate noticeable resource spikes, consider moving them outside normal business hours.

Benefits include:

• Reduced user impact
• Less application contention
• Lower operational disruption

This is particularly important for:

• Database servers
• Application servers
• Virtualization hosts

Keep Wazuh Agents Updated

Newer agent versions often include:

• Performance improvements
• Resource optimizations
• Bug fixes
• Stability enhancements

Regular upgrades help ensure that Syscheck operates as efficiently as possible.

Monitor CPU and Disk Utilization Trends

Resource monitoring should be ongoing rather than reactive.

Track:

• CPU utilization
• Disk throughput
• Scan duration
• Event volumes
• Queue utilization

Trend analysis often reveals emerging issues before they impact production systems.

Test Configuration Changes Before Wide Deployment

Configuration changes should never be deployed blindly across an entire environment.

Recommended workflow:

1. Test in a lab environment.
2. Deploy to a small pilot group.
3. Measure performance impact.
4. Validate security coverage.
5. Roll out gradually.

This approach minimizes operational risk while providing clear visibility into how changes affect both performance and detection capabilities.

By combining careful scope management, targeted monitoring, regular reviews, and proactive performance tracking, organizations can keep Wazuh File Integrity Monitoring efficient, scalable, and effective without allowing CPU consumption to spiral out of control.

Frequently Asked Questions (FAQ)

Question: Why is Wazuh Syscheck using so much CPU?

High CPU usage typically occurs because Syscheck must continuously analyze monitored files and directories.

Common causes include:

• Monitoring too many files
• Recursive monitoring of large directory trees
• Frequent scheduled scans
• Real-time monitoring on busy systems
• Excessive checksum calculations
• Monitoring large files
• High event volumes from temporary or cache directories

In most cases, the issue is related to configuration scope rather than a software defect.

Reviewing monitored paths and reducing unnecessary file coverage is often the fastest way to lower CPU consumption.

Question: Does real-time monitoring consume more CPU than scheduled scans?

Not necessarily.

Real-time monitoring is often more efficient than frequent full scans because the operating system notifies Wazuh when changes occur rather than requiring repeated directory traversal.

However, real-time monitoring can become resource intensive when applied to locations that experience constant file activity.

Examples include:

• Database storage directories
• Application log directories
• Temporary folders
• Container runtime storage

For high-churn environments, scheduled scanning may actually generate less overall overhead.

The most effective approach is usually a combination of:

• Real-time monitoring for critical files
• Scheduled scanning for lower-priority locations

Question: Which directories should never be monitored by FIM?

There is no universal “never monitor” list because every environment has unique requirements.

However, the following locations are frequently excluded because they generate large numbers of low-value file events:

Linux

• /tmp

• /var/tmp

• /var/cache

Windows

• C:\Windows\Temp
• User temp directories
• Browser cache directories

Container environments may also benefit from excluding:

• Docker overlay storage
• Kubernetes ephemeral storage
• Container runtime directories

Focus monitoring efforts on security-relevant files rather than temporary or constantly changing data.

Question: Can I disable checksum calculations entirely?

Yes, but doing so reduces the effectiveness of File Integrity Monitoring.

Checksums provide a reliable method for detecting file content modifications.

Without checksums, Wazuh may rely primarily on metadata such as:

• File size
• Permissions
• Ownership
• Timestamps

While this approach reduces CPU consumption, it can also decrease detection accuracy.

Most organizations choose to keep at least one strong hash algorithm enabled, such as SHA256, rather than disabling checksums entirely.

Question: How often should Wazuh FIM scans run?

The ideal scan frequency depends on the system’s purpose and risk profile.

A common starting point is:

Organizations using real-time monitoring for critical files can often increase scheduled scan intervals without reducing security visibility.

The goal is to balance detection requirements with system performance.

Question: Is high CPU usage normal during the first FIM scan?

Yes.

The initial baseline scan is usually the most resource-intensive scan that Syscheck performs.

During this process, Wazuh must:

• Traverse monitored directories
• Collect metadata
• Calculate checksums
• Build the integrity database

Large environments may experience temporary CPU spikes while this baseline is being created.

After the initial scan completes, resource usage typically decreases significantly.

If high CPU usage continues long after the baseline scan, configuration tuning may be necessary.

Question: Does monitoring large files increase CPU consumption?

Absolutely.

Large files require more processing because Wazuh must read the file contents before calculating checksums.

Examples include:

• Database files
• Virtual machine images
• Backup archives
• Large compressed files

Monitoring a handful of multi-gigabyte files can sometimes consume more CPU than monitoring thousands of small configuration files.

When possible, focus monitoring efforts on files that provide meaningful security value.

Question: Will excluding directories reduce security visibility?

Potentially, but not all visibility reductions are meaningful.

Excluding directories such as:

• Temporary folders
• Cache directories
• Application scratch space

often removes large numbers of low-value events while having little impact on actual threat detection.

The key is to ensure that critical assets remain monitored.

Before excluding any directory, ask:

Would a change in this location represent an important security event?

If the answer is no, exclusion is often appropriate.

Always validate monitoring coverage after making configuration changes.

Question: Can hardware upgrades solve Wazuh FIM CPU issues?

Sometimes, but hardware upgrades should usually be considered after configuration optimization.

Adding:

• More CPU cores
• Faster storage
• Additional memory

can certainly improve performance.

However, upgrading hardware without fixing inefficient monitoring configurations often treats the symptom rather than the root cause.

For example, monitoring millions of unnecessary files will remain inefficient regardless of available hardware.

The best approach is:

1. Optimize configuration.
2. Reduce unnecessary workloads.
3. Scale infrastructure if additional capacity is still required.

Question: How do I know if my FIM configuration is too aggressive?

Your configuration may be overly aggressive if you observe:

• Consistently high CPU utilization
• Long scan durations
• Excessive disk activity
• Alert floods
• Event processing delays
• Monitoring of entire filesystems
• Monitoring of temporary or cache directories

Other warning signs include:

• Scans overlapping with subsequent scans
• High manager queue utilization
• Large numbers of low-value alerts

A well-designed FIM deployment should focus on high-value assets while maintaining acceptable system performance.

If monitoring activity regularly impacts production workloads, the scope should be reviewed and optimized.

Conclusion

Wazuh File Integrity Monitoring is an extremely valuable security capability, but it can become a significant source of CPU consumption when configured too broadly.

In most environments, excessive resource usage can be traced to a handful of common causes, including:

• Monitoring too many files
• Tracking high-churn directories
• Frequent scheduled scans
• Excessive checksum calculations
• Real-time monitoring of busy systems
• Monitoring large files
• Insufficient hardware resources

Fortunately, these issues are usually manageable through careful tuning.

Some of the highest-impact optimization techniques include:

• Reducing the number of monitored directories
• Excluding temporary and cache locations
• Increasing scan intervals
• Limiting checksum calculations
• Restricting real-time monitoring to critical assets
• Excluding large files and container storage locations
• Optimizing manager performance
• Keeping Wazuh agents updated

The most successful FIM deployments balance two competing goals:

1. Maintaining strong security visibility
2. Minimizing operational overhead

Monitoring every file on every system is rarely necessary and often creates more problems than it solves.

Focusing on security-critical assets typically provides better detection coverage while dramatically reducing CPU utilization.

As your environment evolves, regularly review FIM scope, monitor performance trends, validate alert coverage, and test configuration changes before deploying them widely.

By following the optimization strategies outlined in this guide, you can significantly reduce Wazuh integrity monitoring high CPU issues while preserving the visibility needed to detect unauthorized file changes, malware activity, and configuration tampering across your infrastructure.