Wazuh Rootcheck is one of Wazuh’s built-in host-based security modules designed to identify evidence of rootkits, hidden files, suspicious processes, unauthorized system modifications, and other indicators of compromise.

Scheduled Rootcheck scans are particularly important because they continuously verify endpoint integrity without requiring administrator intervention.

If scheduled scans stop running, systems may go days or weeks without being inspected, allowing malware or unauthorized changes to remain undetected.

Unlike a one-time manual scan, automated scheduling ensures every monitored endpoint is checked consistently according to your organization’s security policy.

One of the most frustrating aspects of Rootcheck scheduling problems is that they often fail silently.

The Wazuh agent may remain connected, log collection continues normally, and dashboards appear healthy, yet Rootcheck never executes according to its configured schedule.

Administrators may only discover the issue after noticing stale scan results or missing security alerts.

In this guide, you’ll learn how Wazuh Rootcheck scheduling works, how to recognize when scheduled scans are being ignored, the most common configuration mistakes, and the step-by-step troubleshooting process to restore automatic Rootcheck execution.

You’ll also learn best practices to prevent future scheduling failures and verify that Rootcheck continues operating as expected across your environment.

Understanding Wazuh Rootcheck

What Is Wazuh Rootcheck?

Rootcheck is a host-based security assessment module that runs on Wazuh agents to search for indicators of compromise directly on monitored endpoints.

Instead of relying solely on logs generated by the operating system, Rootcheck actively inspects the system itself for signs that attackers have modified files, hidden processes, installed rootkits, or weakened security configurations.

The module compares system characteristics against a large collection of predefined security checks and known indicators of suspicious activity.

These checks are performed locally on each monitored endpoint before the results are sent to the Wazuh manager for analysis and visualization.

Unlike antivirus software, Rootcheck is designed to identify behavioral indicators and system anomalies rather than relying exclusively on malware signatures.

Purpose of Rootcheck

Rootcheck helps security teams identify threats that may otherwise remain invisible through traditional log monitoring.

Its primary objectives include:

Detecting known rootkit behaviors
Identifying hidden files and directories
Finding hidden processes
Detecting suspicious open ports
Identifying unauthorized system binaries
Discovering insecure configurations
Monitoring unauthorized changes to critical system components
Supporting compliance and security auditing

By performing recurring integrity assessments, Rootcheck provides additional visibility into endpoint health beyond standard event logs.

How It Detects Rootkits, Hidden Processes, and Suspicious System Modifications

Rootcheck performs numerous security validation checks during every scan.

These include:

Looking for known rootkit signatures
Detecting hidden processes by comparing multiple system information sources
Searching for hidden network ports
Inspecting suspicious files and directories
Verifying permissions on sensitive system files
Checking for unauthorized kernel modules (platform dependent)
Detecting anomalies in common system binaries
Looking for evidence of tampering within critical operating system components

Many of these techniques follow long-established host-based intrusion detection principles recommended by organizations such as MITRE and National Institute of Standards and Technology, which emphasize continuous endpoint monitoring as part of a defense-in-depth strategy.

Relationship Between Rootcheck and the Wazuh Agent

Rootcheck does not run on the Wazuh manager itself.

Instead, every Wazuh agent performs Rootcheck scans locally on the endpoint where it is installed.

After completing a scan, the agent sends the findings back to the Wazuh manager, where alerts are generated, indexed, and displayed in the dashboard.

This architecture provides several benefits:

Reduces centralized processing
Allows each endpoint to inspect its own filesystem
Improves scalability across large deployments
Enables offline detection if temporary connectivity issues occur

If the Wazuh agent stops functioning correctly, Rootcheck scheduling also stops because the agent is responsible for launching the scans.

Related Guide: How to Upgrade a Wazuh Agent

How Scheduled Rootcheck Scans Work

Rootcheck is designed to execute automatically according to the schedule defined within the agent configuration.

Administrators typically enable the module once and allow it to perform recurring scans without manual intervention.

Scan Scheduling Mechanism

The scheduling engine is configured through the <rootcheck> section of the agent’s ossec.conf file.

Common scheduling parameters include:

Scan frequency
Scan start time
Scan interval
Enable/disable status
Scan on startup
Skip network filesystems
Scan specific directories

The agent continuously monitors these settings and launches Rootcheck whenever the configured schedule is reached.

Default Scan Intervals

Although administrators can customize scheduling, Wazuh commonly performs Rootcheck at regular intervals suitable for ongoing endpoint monitoring.

Many organizations choose intervals such as:

Every 12 hours
Every 24 hours
Daily during off-peak hours
Weekly for low-risk systems

The appropriate interval depends on:

Number of endpoints
System performance
Compliance requirements
Risk tolerance
Available maintenance windows

Security guidance from NIST recommends continuous or regularly scheduled security monitoring rather than relying solely on manual inspections.

Difference Between Scheduled Scans and Manual Scans

Manual scans are started by an administrator when immediate verification is needed.

Scheduled scans occur automatically without user interaction.

Scheduled Scan	Manual Scan
Runs automatically	Started manually
Uses configured schedule	Runs immediately
Supports continuous monitoring	Used mainly for troubleshooting
Ideal for production environments	Useful after configuration changes
Detects ongoing changes over time	Provides point-in-time verification

If manual scans work correctly but scheduled scans do not, the problem usually lies with scheduling configuration rather than the Rootcheck engine itself.

Where Scan Results Are Stored

After Rootcheck finishes scanning:

Results are generated on the local agent.
Findings are forwarded to the Wazuh manager.
Alerts are indexed.
Data becomes searchable in the Wazuh dashboard.
Historical scan information remains available for investigations.

Administrators can also review local agent logs and manager logs when troubleshooting scheduling problems.

Related Guides:

Symptoms That Rootcheck Scheduled Scans Are Being Ignored

Recognizing the symptoms early can significantly reduce the amount of time systems remain unmonitored.

In many environments, scheduled Rootcheck failures do not generate obvious error messages, making it important to recognize indirect indicators.

Rootcheck Never Runs Automatically

One of the clearest warning signs is that Rootcheck never executes unless an administrator starts it manually.

You may observe:

No recurring Rootcheck activity in logs
No scheduled execution after system startup
Long gaps between scans
Endpoints remaining unchanged for days or weeks
Rootcheck reports only after manual execution

This usually indicates a scheduling configuration problem rather than a detection engine failure.

No New Rootcheck Alerts

Another common symptom is that previously active Rootcheck alerts suddenly stop appearing.

Examples include:

No rootkit detection events
No hidden file checks
No system audit findings
No integrity warnings

While a clean system can naturally produce few alerts, a complete absence of Rootcheck activity across many endpoints often suggests scheduled scans are no longer running.

Scan Timestamps Never Change

Administrators should periodically review the last successful scan time.

Potential warning signs include:

Identical timestamps every day
Scan dates several weeks old
No recent inventory updates
Historical results without new entries

Static timestamps almost always indicate that scheduled execution has stalled.

Manual Scans Work but Scheduled Ones Do Not

This is one of the most useful troubleshooting clues.

If launching Rootcheck manually produces results immediately, the detection engine is functioning correctly.

The problem is usually isolated to:

Scheduling parameters
Disabled Rootcheck module
Configuration syntax errors
Agent configuration distribution
Timing configuration conflicts

Because manual execution succeeds, administrators can generally rule out corrupted Rootcheck binaries or detection logic.

Why This Narrows Down the Problem

Manual success confirms several critical components are operating normally:

Rootcheck binaries
Agent permissions
Communication with the manager
Alert generation
Dashboard indexing

The remaining investigation should focus primarily on why automatic scheduling is not triggering.

Typical Configuration Issues

Some of the most common scheduling problems include:

<disabled> accidentally set to yes
Invalid scheduling parameters
Incorrect XML formatting
Configuration overwritten by centralized management
Agent never reloaded after configuration changes
Unsupported parameter combinations

Even a small XML syntax mistake can prevent the scheduling engine from loading correctly.

Missing Rootcheck Alerts in the Dashboard

Sometimes Rootcheck executes successfully, but administrators never see the results in the dashboard.

This creates the impression that scheduled scans are being ignored when the issue actually lies elsewhere.

Dashboard Indicators

Possible dashboard symptoms include:

Empty Rootcheck sections
No recent Rootcheck alerts
Missing inventory updates
No searchable Rootcheck events
Dashboards showing outdated information

If multiple agents exhibit the same behavior simultaneously, the issue may involve indexing or dashboard components rather than Rootcheck itself.

Manager Logs vs. Agent Logs

Comparing logs helps determine where the breakdown occurs.

Review:

Agent logs

Was Rootcheck started?
Did the scan complete?
Were results transmitted?

Manager logs

Were events received?
Were alerts generated?
Were indexing errors reported?

Tracing the data flow between the agent and manager helps isolate whether the failure occurs during execution, transmission, or visualization.

Stale Rootcheck Inventory

One of the easiest indicators to overlook is stale inventory information.

Even if dashboards remain operational, the underlying Rootcheck data may never refresh.

Outdated Scan Results

Signs include:

Inventory dates that never update
Repeated identical findings
Missing newly created files
No recent security assessments
Old endpoint metadata remaining unchanged

Administrators often discover this issue during audits or compliance reviews rather than through routine monitoring.

Compliance and Security Risks

Ignoring scheduled Rootcheck failures can have significant operational consequences.

Potential risks include:

Longer attacker dwell time
Missed rootkit infections
Undetected privilege escalation
Incomplete security audits
Reduced compliance evidence
Lower confidence in endpoint monitoring

Security experts, including guidance from NIST’s continuous monitoring framework, emphasize that security assessments must occur on a recurring basis to maintain an accurate understanding of system risk rather than relying on occasional manual checks.

Common Causes of Ignored Wazuh Rootcheck Scans

There are several reasons why Wazuh Rootcheck may stop running automatically even though the agent appears healthy.

In many cases, the problem is not a bug in Rootcheck itself but rather a configuration, communication, or operating system issue that prevents scheduled execution.

Understanding these common causes allows administrators to narrow their troubleshooting efforts and restore automated scans much more quickly.

Rootcheck Is Disabled

The simplest explanation is often the correct one. Rootcheck has been disabled.

Whether through a local configuration change, centralized policy, or accidental modification during an upgrade, a disabled Rootcheck module will never launch scheduled scans.

Disabled Module Configuration

The Rootcheck module is controlled by the <rootcheck> section inside the agent’s ossec.conf file.

For example:

<rootcheck>
  <disabled>no</disabled>
</rootcheck>

If this setting is changed to:

<disabled>yes</disabled>

Rootcheck will not perform either scheduled or startup scans until the module is re-enabled.

Administrators should always verify this setting before investigating more complex causes.

Agent Configuration Errors

Even when Rootcheck is enabled, configuration mistakes can prevent the scheduler from initializing correctly.

Common examples include:

Missing XML tags
Incorrect nesting of configuration elements
Duplicate Rootcheck sections
Unsupported configuration options
Typographical errors
Invalid parameter values

Because Wazuh reads the configuration during agent startup, a malformed configuration can prevent Rootcheck from loading altogether.

Incorrect Scan Frequency Settings

Scheduling problems frequently originate from incorrect frequency configuration.

Although Rootcheck supports flexible scheduling, unrealistic or invalid values may prevent scans from executing as expected.

Invalid Frequency Values

Administrators sometimes configure:

Extremely long intervals
Unsupported values
Invalid numeric formats
Negative values
Conflicting scheduling parameters

For example, configuring a scan interval measured in several months may appear as though Rootcheck has stopped working when it is simply waiting for the next scheduled execution.

Always verify that configured intervals align with operational expectations.

Misconfigured Scheduling Options

Several scheduling parameters work together.

Improper combinations can delay or suppress automatic execution.

Examples include:

Startup scans disabled
Frequency values conflicting with scan timing
Incorrect time formatting
Overlapping scheduling directives
Disabled recurring scans

Reviewing every Rootcheck scheduling option together is far more effective than checking individual settings in isolation.

Configuration Overrides

Many enterprise environments manage Wazuh agents through centralized configuration rather than local configuration files.

As a result, local changes may never take effect.

Centralized Configuration Overriding Local Settings

The Wazuh manager can distribute configuration files to agents.

If centralized management defines different Rootcheck settings than those stored locally, the centralized configuration takes precedence.

Administrators often encounter situations where:

Local changes disappear after reconnecting
Settings revert after agent restart
Rootcheck remains disabled despite local edits

When troubleshooting, always determine which configuration source is authoritative.

Agent Groups

Agents assigned to different groups may receive different Rootcheck configurations.

Examples include:

Production servers
Development systems
Windows endpoints
Linux servers
Database servers

If only one group experiences missing scheduled scans, compare its assigned configuration with groups where Rootcheck functions correctly.

Wazuh Agent Problems

Since Rootcheck executes on the endpoint itself, the Wazuh agent must be operating normally.

Any interruption to the agent also interrupts scheduled Rootcheck scans.

Agent Disconnected

If the manager reports an agent as disconnected:

Scheduled scans may still execute locally.
Results cannot be forwarded.
Dashboard data becomes outdated.
Alerts never reach the manager.

Disconnected agents should always be investigated promptly.

Agent Service Not Running

If the Wazuh agent service stops unexpectedly, no scheduled modules execute.

This affects:

Rootcheck
Logcollector
File Integrity Monitoring
Security Configuration Assessment
Active Response communications

Verify the service status before modifying any configuration.

Registration Issues

Improper registration may also interfere with normal operation.

Potential problems include:

Duplicate agent IDs
Authentication failures
Lost registration keys
Corrupted enrollment information

These issues may prevent configuration updates or communication with the manager.

Why Is client.keys File Empty? Restoring Lost Wazuh Agents

Manager Communication Failures

Even when scheduled scans complete successfully, communication failures can make it appear as though Rootcheck never ran.

Connectivity Problems

Common network-related issues include:

Packet loss
VPN interruptions
DNS failures
Network segmentation
Routing problems

If scan results never reach the manager, dashboards remain unchanged despite successful local execution.

Authentication Issues

Authentication failures may prevent agents from sending Rootcheck results.

Potential causes include:

Invalid certificates
Expired credentials
Key mismatches
Enrollment failures

Authentication problems often generate errors in both agent and manager logs.

How to Fix Wazuh Certificate Errors

Firewall Restrictions

Network security devices can unintentionally block communication between agents and managers.

Verify that:

Required Wazuh ports are open
Firewall policies permit bidirectional communication
Network inspection devices are not terminating sessions
Host firewalls allow agent traffic

Firewall changes frequently explain why scheduling appears to stop after infrastructure updates.

Operating System Permissions

Rootcheck requires sufficient operating system privileges to inspect protected resources.

Insufficient permissions can prevent scans from completing successfully.

Insufficient Privileges

Limited user permissions may prevent Rootcheck from accessing:

System binaries
Protected directories
Security-related files
Kernel information
Sensitive configuration files

Permission errors often appear in agent logs during scan execution.

Linux Permission Issues

On Linux systems, administrators should verify:

File permissions
SELinux policies
AppArmor restrictions
Ownership of monitored directories
Access to system binaries

Mandatory access control frameworks may block portions of a Rootcheck scan even when the agent itself is functioning normally.

Windows Administrative Requirements

On Windows, the Wazuh agent should generally run with sufficient administrative privileges to inspect protected operating system resources.

Without elevated permissions, Rootcheck may be unable to:

Enumerate certain processes
Inspect protected registry locations
Access security-sensitive directories
Read protected system files

Resource Protection Features

Some scheduling failures are intentional.

Organizations sometimes configure systems to reduce security scanning during periods of high resource utilization.

CPU Throttling

Heavy CPU utilization may delay scheduled Rootcheck execution.

Examples include:

Virtualized environments
Resource-constrained servers
High-load database systems
Build servers
Containers sharing host resources

While this protects system performance, it can also create longer-than-expected intervals between scans.

Performance Optimization Settings

Administrators may intentionally tune Rootcheck to reduce resource usage.

Examples include:

Longer scan intervals
Reduced scan scope
Excluded directories
Startup scans disabled
Background scheduling adjustments

Performance tuning should always balance resource consumption with security visibility.

Scan Interruptions

Rootcheck scans may also terminate before completion because of:

Agent restarts
System reboots
Service crashes
Forced shutdowns
Operating system updates

Repeated interruptions can create the impression that scheduled scans are being ignored when they are actually being aborted before finishing.

Step-by-Step Troubleshooting

A structured troubleshooting process helps isolate the root cause quickly while avoiding unnecessary configuration changes.

Start with the simplest checks before investigating communication, logging, and scheduling behavior.

Step 1: Verify That Rootcheck Is Enabled

Before reviewing logs or network connectivity, confirm that the module is actually enabled.

Check ossec.conf

Open the agent’s ossec.conf file and locate the <rootcheck> section.

Verify that:

The section exists
It is properly formatted
It contains valid scheduling options
No duplicate Rootcheck sections exist

Confirm Module Status

Verify that:

<disabled> is set to no
The agent successfully loaded the configuration
No startup errors reference Rootcheck

If Rootcheck is disabled, scheduled scans will never execute regardless of any other settings.

Step 2: Review Rootcheck Configuration

Once the module is enabled, review each scheduling parameter carefully.

Frequency

Verify that the configured frequency:

Matches your intended schedule
Uses valid values
Is not excessively long
Has not been accidentally modified

Scan Options

Review settings controlling scan behavior, including:

Startup scans
Filesystem checks
Rootkit detection options
Hidden process detection
Hidden port detection

Ensure these options align with your organization’s monitoring requirements.

Directories

Review all monitored directories.

Look for:

Incorrect paths
Missing mount points
Invalid directory names
Operating-system-specific paths

Incorrect directory definitions may prevent portions of the scan from running correctly.

Ignore Lists

Large ignore lists may unintentionally exclude important areas of the filesystem.

Verify that:

Critical directories remain monitored
Ignore rules are intentional
Wildcards are not overly broad

Step 3: Validate the Configuration

Even small XML mistakes can prevent Rootcheck from loading.

Check for XML Syntax Errors

Inspect the configuration for:

Missing closing tags
Invalid nesting
Duplicate elements
Misspelled options

Configuration validation should always precede service restarts.

Verify Configuration Loading

After restarting the agent, verify that the configuration loaded successfully.

Check logs for messages indicating:

Successful initialization
Configuration parsing
Module startup
Scheduling activation

Restart Services After Changes

Configuration changes are not always applied immediately.

Restart the Wazuh agent after modifying Rootcheck settings so the updated configuration is loaded.

Step 4: Check Wazuh Agent Status

Rootcheck depends entirely on a healthy agent.

Verify the Service Is Running

Confirm that:

The Wazuh agent service is active
It starts automatically
No recent crashes occurred
The service remains stable after startup

Confirm Manager Connectivity

Verify that the agent maintains communication with the manager.

Check for:

Connected status
Recent heartbeats
Successful message transmission
No repeated reconnect attempts

Inspect Agent Health

A healthy agent should:

Load all enabled modules
Process logs normally
Receive configuration updates
Communicate consistently with the manager

Step 5: Review Agent Logs

Agent logs often reveal exactly why scheduled scans failed.

Linux Log Locations

On most Linux systems, review:

/var/ossec/logs/ossec.log

Look for:

Rootcheck initialization
Scheduling events
Permission errors
Scan completion messages

Windows Log Locations

On Windows, review the Wazuh agent log file for:

Module startup
Configuration loading
Scheduling activity
Access-denied errors

Rootcheck-Related Messages

Pay particular attention to messages referencing:

Rootcheck
Scheduler
Scan frequency
Configuration parsing
Module initialization
Permission failures

Step 6: Review Manager Logs

If the agent appears healthy, move to the manager.

Connection Errors

Look for:

Agent disconnects
Authentication failures
Transmission errors
Network interruptions

Configuration Deployment

Confirm that:

Correct agent groups are assigned
Configuration deployment succeeded
No centralized overrides replaced local settings

Scheduling Messages

Manager logs may reveal:

Configuration synchronization
Agent reloads
Policy distribution
Scheduling updates

Step 7: Force a Manual Rootcheck Scan

Manual execution helps determine whether the issue involves scheduling or the Rootcheck engine itself.

How to Trigger a Manual Scan

Start a manual Rootcheck scan using the appropriate Wazuh management tools or by restarting the module according to your deployment method.

The exact procedure varies depending on your operating system and Wazuh version, so refer to the official documentation if needed.

Compare Manual vs. Scheduled Behavior

If the manual scan succeeds but scheduled scans never occur, focus your investigation on:

Scheduling configuration
Configuration deployment
Timing settings
Agent policy synchronization

This comparison significantly narrows the troubleshooting scope.

Step 8: Verify Dashboard Results

After making changes, confirm that Rootcheck is once again operating normally.

Confirm New Alerts

Verify that:

New Rootcheck events appear
Alerts reflect recent scans
Inventory data updates
Event counts increase appropriately

Check Timestamps

Recent scan timestamps should match the configured schedule.

If timestamps continue updating automatically after the manual test, scheduling has likely been restored.

Validate Event Ingestion

Finally, confirm the entire processing pipeline works correctly:

Agent completes the scan
Results reach the manager
Events are indexed
Dashboard displays new findings

Related Guide: How to Test Wazuh Rules

Reviewing Rootcheck Configuration Options

Understanding the key Rootcheck configuration options makes it easier to diagnose scheduling issues and optimize scans for your environment.

Frequency (`frequency`)

The frequency option determines how often Rootcheck performs scheduled scans.

How Scan Intervals Work

The value specifies the interval between automatic executions.

After a scan completes, the scheduler waits for the configured interval before starting the next one.

Shorter intervals provide more frequent visibility but consume additional system resources, while longer intervals reduce overhead at the cost of slower detection of unauthorized changes.

Choosing an Appropriate Schedule

An effective schedule depends on factors such as:

Endpoint criticality
Compliance requirements
Available system resources
Operational hours
Acceptable detection latency

Critical production servers generally benefit from more frequent scans than low-risk development systems.

Scan on Startup (`scan_on_start`)

This option determines whether Rootcheck runs automatically whenever the Wazuh agent starts.

Benefits

Enabling startup scans provides several advantages:

Immediate integrity verification after reboot
Faster detection following maintenance windows
Reduced time before first scheduled scan
Improved visibility after agent installation

Potential Drawbacks

Startup scans may temporarily increase resource utilization during system boot, particularly on servers hosting many applications or large filesystems.

Organizations with strict boot-time performance requirements sometimes disable startup scans and rely solely on scheduled execution.

Disabled (`disabled`)

The disabled setting controls whether the Rootcheck module operates at all.

Ensuring the Module Is Active

For automatic scanning to function:

The module must be enabled.
Configuration must load successfully.
The agent must restart after changes.
No centralized configuration should override the setting.

Always verify this option first during troubleshooting because it is the quickest potential fix.

Skip NFS (`skip_nfs`)

Network-mounted filesystems can significantly increase scan duration.

The skip_nfs option determines whether Rootcheck ignores these locations.

Purpose

Skipping NFS-mounted storage can:

Reduce scan time
Lower network traffic
Prevent delays
Improve scheduling consistency

When to Enable or Disable

Enable this option when:

Large network shares exist
NFS contains non-critical data
Scan performance is a concern

Disable it when:

Sensitive data resides on network storage
Compliance requires inspecting mounted filesystems
Security policies mandate complete filesystem coverage

Ignore Directories and Files

Rootcheck supports excluding specific paths from scanning.

Reducing False Positives

Ignore rules help eliminate expected changes from locations such as:

Temporary directories
Application caches
Build artifacts
Frequently changing log directories

Proper exclusions reduce alert fatigue without sacrificing meaningful visibility.

Related Guide: How to Reduce False Positives in Wazuh

Avoiding Unnecessary Scans

Excluding non-essential directories also improves performance by:

Shortening scan duration
Reducing disk activity
Lowering CPU utilization
Improving scheduling reliability
Allowing Rootcheck to focus on high-value system locations

When creating ignore lists, avoid excluding critical operating system directories or security-sensitive files, as doing so can create blind spots that attackers may exploit.

Troubleshooting Common Rootcheck Scheduling Scenarios

Even after verifying that Rootcheck is enabled and reviewing the configuration, administrators may still encounter situations where scheduled scans behave inconsistently.

These scenarios often point to specific underlying issues that can be identified with a systematic approach.

Rootcheck Runs Only After Restarting the Agent

If Rootcheck executes immediately after restarting the Wazuh agent but never runs again, the scheduler is likely failing after its initial execution.

Common causes include:

Invalid scheduling parameters
Incorrect frequency values
Configuration not loading completely
Service interruptions
Configuration overrides from the manager
Bugs introduced during recent upgrades

To troubleshoot this scenario:

Verify the configured scan interval.
Monitor the agent log until the next scheduled execution.
Confirm that no errors occur after the initial scan.
Ensure the agent remains running continuously.
Verify that centralized configuration has not replaced local settings.

A successful startup scan followed by no additional scans almost always indicates a scheduling problem rather than a Rootcheck detection issue.

Rootcheck Stops Running After Configuration Changes

Configuration changes can unintentionally disable Rootcheck or prevent the scheduler from loading properly.

Typical causes include:

XML syntax errors
Invalid configuration parameters
Incorrect placement of Rootcheck options
Duplicate <rootcheck> sections
Unsupported configuration values

If Rootcheck stops immediately after editing ossec.conf:

Compare the modified configuration with the previous working version.
Review agent logs for configuration parsing errors.
Validate the XML syntax.
Restart the Wazuh agent after making corrections.

Whenever possible, test configuration changes on a non-production agent before deploying them across the environment.

Rootcheck Works on Some Agents but Not Others

When only a subset of agents experiences scheduling problems, the issue is rarely related to the Wazuh manager itself.

Instead, investigate differences between affected and unaffected endpoints, such as:

Operating system versions
Agent versions
Assigned agent groups
Local configuration
Network connectivity
Available system resources

Create a comparison checklist that includes:

Rootcheck configuration
Agent status
Manager connectivity
Log messages
Assigned centralized policies

If multiple agents within the same group exhibit identical behavior, review the shared configuration distributed to that group.

Related Guide: How to Upgrade a Wazuh Agent

Rootcheck Runs Irregularly

Some administrators report that Rootcheck executes occasionally but not according to the configured schedule.

Possible causes include:

Resource throttling
Frequent system reboots
Long-running scans
Configuration synchronization delays
Heavy CPU utilization
Virtual machine suspension or hibernation

Review historical execution times to determine whether scans are:

Delayed by a consistent amount
Skipped entirely
Interrupted before completion
Triggered only after specific events

Irregular execution often indicates that external system conditions are interfering with the scheduler rather than a configuration error.

Rootcheck Generates No Alerts Despite Running

A successful Rootcheck scan does not necessarily produce alerts.

If scans complete normally but no alerts appear:

Verify that the scan actually inspected the intended directories.
Confirm that results were forwarded to the manager.
Review indexing status.
Search raw events instead of relying solely on dashboard visualizations.
Check whether alert suppression or filtering rules are hiding events.

A clean endpoint may legitimately generate few or no alerts. The goal is to verify that scans are executing successfully, not necessarily that detections occur during every execution.

If events exist in the manager logs but never appear in the dashboard, investigate indexing and visualization components rather than Rootcheck itself.

Related Guides:

Rootcheck Configuration Is Overwritten by Centralized Management

One of the most common sources of confusion is centralized configuration management.

Administrators edit the local ossec.conf file, restart the agent, verify the changes, and later discover that the configuration has reverted automatically.

This typically occurs because:

Shared configuration is enabled.
The agent belongs to a managed group.
The manager distributes updated configuration files.
Local settings are intentionally replaced.

When this happens:

Determine whether centralized management is enabled.
Identify the agent’s assigned group.
Review the shared configuration on the manager.
Modify the centralized policy instead of the local configuration whenever appropriate.

Managing configuration from a single source reduces administrative overhead but requires administrators to understand which settings have priority.

Using Centralized Configuration Correctly

Centralized configuration is one of Wazuh’s most valuable management features because it allows administrators to deploy consistent settings across hundreds or thousands of endpoints.

However, it can also introduce unexpected behavior if administrators are unaware of how configuration inheritance works.

The following practices help ensure Rootcheck scheduling remains predictable across the entire environment.

Understanding Agent Groups

Agent groups allow administrators to apply different configurations to different categories of endpoints.

Examples include:

Linux servers
Windows workstations
Domain controllers
Database servers
Web servers
Development systems

Each group can receive its own Rootcheck configuration, making it possible to customize scan frequency, exclusions, and scheduling based on the role of the system.

For example:

Agent Group	Suggested Rootcheck Strategy
Domain Controllers	Frequent scans with minimal exclusions
Production Linux Servers	Daily scans during maintenance windows
Development Systems	Less frequent scans to reduce overhead
Workstations	Daily or twice-daily scans
Test Environments	Flexible scheduling for experimentation

Keeping group assignments organized simplifies troubleshooting when scheduling problems affect only a subset of systems.

Verifying Shared Configuration

Whenever Rootcheck behaves unexpectedly, verify that the shared configuration being distributed by the Wazuh manager matches your expectations.

Review:

Rootcheck enable/disable status
Scan frequency
Ignore lists
Startup scan settings
Directory exclusions
Group-specific overrides

After updating shared configuration:

Confirm the manager successfully distributed the changes.
Verify the agent received the updated configuration.
Restart the agent if required.
Monitor logs for successful configuration loading.

Comparing the effective configuration on the endpoint with the configuration stored on the manager helps identify synchronization issues quickly.

Preventing Configuration Conflicts

Configuration conflicts commonly occur when multiple administrators manage different parts of the environment.

Examples include:

Local configuration differs from shared configuration.
Multiple agent groups define conflicting settings.
Configuration changes are deployed without validation.
Legacy configuration files remain after upgrades.

To minimize conflicts:

Use centralized configuration whenever possible.
Avoid editing local files unless necessary.
Maintain version control for configuration changes.
Document group-specific exceptions.
Periodically audit agent configurations.

A standardized configuration management process reduces the likelihood of inconsistent Rootcheck behavior across large deployments.

Deploying Configuration Changes Safely

Poorly tested configuration updates can disable scheduled Rootcheck scans across hundreds of endpoints.

A safer deployment workflow includes:

Validate the XML syntax.
Test the configuration on a small pilot group.
Review agent logs for errors.
Confirm scheduled scans execute correctly.
Gradually deploy the configuration to additional agent groups.
Monitor dashboard activity after deployment.

This staged approach minimizes operational risk while ensuring configuration changes behave as expected.

Performance Considerations

Rootcheck is designed to operate with minimal impact on monitored systems, but scan frequency and configuration choices can significantly affect resource consumption.

Proper tuning helps maintain strong security visibility without introducing unnecessary performance overhead.

Choosing an Appropriate Scan Interval

Selecting the right scan interval requires balancing security requirements against available system resources.

Factors to consider include:

System criticality
Compliance obligations
Endpoint performance
Rate of system change
Acceptable detection window

As a general guideline:

Environment	Typical Scan Frequency
Domain Controllers	Every 6–12 hours
Production Servers	Every 12–24 hours
User Workstations	Every 24 hours
Development Systems	Every 24–48 hours
Low-Priority Systems	Every 48–72 hours

These examples are starting points; organizations should adjust intervals based on their own risk assessments, operational requirements, and performance testing.

Reducing Resource Usage

If Rootcheck noticeably impacts endpoint performance, consider optimizing the scan configuration instead of disabling the module.

Potential optimizations include:

Excluding non-critical directories
Skipping large temporary directories
Enabling skip_nfs when appropriate
Removing unnecessary scan targets
Avoiding overlapping security scans
Increasing scan intervals for low-risk systems

Regularly review excluded paths to ensure important system areas remain protected.

Scheduling Scans During Off-Peak Hours

Running Rootcheck during periods of low system activity minimizes its impact on users and business applications.

Good scheduling windows often include:

Overnight maintenance periods
Weekends
Planned maintenance windows
Periods with historically low CPU utilization

Coordinating Rootcheck with other maintenance activitiesfsuch as backups, vulnerability scans, or software updates, can help avoid resource contention while keeping endpoint monitoring consistent.

Avoiding Excessive Scan Frequency

Running Rootcheck too frequently does not always improve security and may reduce overall system efficiency.

Excessive scheduling can lead to:

Increased CPU utilization
Higher disk I/O
Longer scan queues
Overlapping scan executions
Additional log volume
Reduced endpoint responsiveness

The official Wazuh documentation recommends configuring modules according to the capabilities of the monitored systems rather than using the shortest possible interval for every endpoint.

An effective Rootcheck deployment prioritizes consistent, reliable scheduling over unnecessarily frequent scans.

Well-planned intervals provide continuous endpoint visibility while minimizing operational impact.

Best Practices for Reliable Wazuh Rootcheck Scheduling

Preventing Rootcheck scheduling problems is far easier than troubleshooting them after they occur.

By following a few operational best practices, administrators can significantly reduce the likelihood of missed scans while ensuring consistent endpoint monitoring across their environment.

Standardize Rootcheck Configurations

Inconsistent configurations are one of the leading causes of scheduling issues in large Wazuh deployments.

To maintain consistency:

Use standardized Rootcheck settings across similar systems.
Define scan intervals based on endpoint roles.
Keep ignore lists consistent within each agent group.
Avoid unnecessary local configuration changes.
Maintain version-controlled configuration files.

Standardized configurations simplify troubleshooting because administrators can quickly identify endpoints that deviate from the approved baseline.

Monitor Agent Health Regularly

Since Rootcheck depends on the Wazuh agent, maintaining healthy agents is essential for reliable scheduled scans.

Regularly verify:

Agent connectivity
Service uptime
Configuration synchronization
Recent check-ins
Resource utilization
Software version consistency

Automated health monitoring can help identify disconnected or malfunctioning agents before scheduled scans begin failing.

Test Scheduled Scans Periodically

A correctly configured scheduler today does not guarantee it will continue working after upgrades, infrastructure changes, or policy updates.

Periodically verify that:

Scans execute according to schedule.
New alerts appear as expected.
Scan timestamps continue updating.
Results reach the manager.
Dashboard data reflects recent activity.

Rather than waiting for an audit or incident response exercise, incorporate Rootcheck scheduling validation into routine maintenance procedures.

Keep Wazuh Updated

New Wazuh releases frequently include bug fixes, performance improvements, security enhancements, and compatibility updates that can improve overall system reliability.

Before upgrading:

Review the release notes.
Test upgrades in a staging environment.
Verify Rootcheck scheduling after deployment.
Confirm centralized configurations remain intact.

Maintaining supported versions also reduces the likelihood of encountering issues that have already been resolved in newer releases.

Document Configuration Changes

Many scheduling issues originate from undocumented configuration changes.

Maintain records of:

Modified Rootcheck settings
Scan frequency adjustments
Ignore list updates
Agent group assignments
Configuration deployment dates
Administrator approvals

Good documentation makes it easier to identify when scheduling problems first appeared and what changes may have introduced them.

Monitor Rootcheck Logs Continuously

Rootcheck logs often provide early warning signs before scheduled scans stop entirely.

Monitor for:

Failed scan attempts
Permission errors
Configuration parsing issues
Scheduler warnings
Communication failures
Unexpected module restarts

Integrating these logs into your organization’s monitoring and alerting workflow enables administrators to detect scheduling problems before they impact security visibility.

Related Guide: How to Configure Wazuh Log Retention

Use Configuration Management Carefully

Centralized configuration is extremely powerful, but improper use can unintentionally disable Rootcheck across large numbers of endpoints.

To reduce risk:

Test configuration changes before production deployment.
Apply changes to a small pilot group first.
Validate XML before distributing updates.
Review agent group assignments regularly.
Maintain configuration backups.
Use change control procedures for production environments.

Configuration management should improve consistency, not introduce new scheduling problems.

Frequently Asked Questions (FAQ)

Question: Why is Wazuh Rootcheck not running automatically?

The most common reasons include:

Rootcheck is disabled in ossec.conf.
Invalid scheduling or frequency settings.
XML configuration errors.
Centralized configuration overriding local settings.
The Wazuh agent is offline or stopped.
Communication problems between the agent and manager.
Insufficient operating system permissions.

Begin troubleshooting by verifying that the Rootcheck module is enabled and that the Wazuh agent is running normally before investigating more advanced causes.

Question: How do I manually start a Rootcheck scan?

The exact procedure depends on your Wazuh version and deployment method.

In general, you can initiate a manual Rootcheck scan using Wazuh management tools or by restarting the appropriate module or agent, then verify the results in the agent logs and Wazuh dashboard.

Manual scans are particularly useful for determining whether the issue lies with the Rootcheck engine itself or with the scheduling mechanism.

Question: How often should Wazuh Rootcheck run?

There is no universal scan interval that fits every environment.

The ideal frequency depends on factors such as:

System criticality
Compliance requirements
Available resources
Organizational risk tolerance

Many organizations schedule Rootcheck to run every 12 to 24 hours for production systems, while lower-risk endpoints may use longer intervals.

The objective is to balance timely detection with acceptable resource usage.

Question: Does restarting the Wazuh agent trigger a Rootcheck scan?

It can, depending on your configuration.

If the scan_on_start option is enabled, restarting the Wazuh agent typically initiates a Rootcheck scan during startup. If this option is disabled, the next scan will occur according to the configured schedule.

A startup scan should not be considered a substitute for reliable recurring scheduled scans.

Question: Can centralized configuration disable Rootcheck?

Yes.

If your deployment uses centralized configuration, the Wazuh manager can override local agent settings, including enabling or disabling the Rootcheck module.

If local configuration changes do not persist, review:

Agent group assignments
Shared configuration files
Centralized deployment policies

Always determine whether the effective configuration originates from the local agent or the manager before making additional changes.

Question: Where are Rootcheck logs stored?

Rootcheck activity is typically recorded in the Wazuh agent logs.

On Linux systems, the primary log file is commonly located at:

/var/ossec/logs/ossec.log

On Windows, Rootcheck messages are recorded in the Wazuh agent log within the installation directory.

In addition to agent logs, administrators should also review manager logs when investigating communication or event-ingestion problems.

Question: Why do manual Rootcheck scans work but scheduled scans fail?

This behavior usually indicates that the Rootcheck engine is functioning correctly while the scheduling mechanism is not.

Common causes include:

Incorrect scheduling configuration
Invalid frequency values
Disabled recurring scans
Centralized configuration overrides
Agent scheduling problems

Because manual execution succeeds, troubleshooting should focus on scheduler configuration rather than Rootcheck detection capabilities.

Question: Does Rootcheck require root or administrator privileges?

Rootcheck performs inspections of protected operating system resources, so it generally requires sufficient privileges to access sensitive files, processes, and system information.

On Linux systems, inadequate permissions or mandatory access control frameworks such as SELinux or AppArmor may restrict certain checks.

On Windows, the Wazuh agent should run with appropriate administrative privileges to inspect protected system resources effectively.

Conclusion

Wazuh Rootcheck plays a vital role in detecting rootkits, hidden processes, unauthorized system modifications, and other indicators of compromise that may not be visible through traditional log monitoring alone.

When scheduled scans stop running, organizations lose an important layer of continuous endpoint visibility, potentially allowing security issues to go unnoticed for extended periods.

As you’ve seen throughout this guide, ignored Rootcheck scans are most commonly caused by disabled modules, incorrect scheduling parameters, configuration syntax errors, centralized configuration overrides, agent connectivity problems, insufficient permissions, or communication failures between the agent and manager.

Fortunately, these issues can usually be resolved by following a structured troubleshooting process rather than making random configuration changes.

Start by confirming that Rootcheck is enabled, review the scheduling configuration, validate the ossec.conf file for XML errors, verify agent health, examine both agent and manager logs, compare manual and scheduled scan behavior, and confirm that new events are reaching the Wazuh dashboard.

This systematic approach helps isolate the root cause quickly while minimizing unnecessary downtime.

Finally, remember that reliable Rootcheck scheduling requires ongoing maintenance, not just one-time configuration.

Regularly test scheduled scans, monitor Rootcheck logs, keep Wazuh up to date, document configuration changes, and carefully manage centralized configuration policies.

By incorporating these best practices into your operational workflow, you can ensure that Rootcheck continues to provide consistent, automated endpoint monitoring and strengthen the overall security posture of your Wazuh deployment.

Fix Wazuh Rootcheck: What to Do When Scheduled Scans Are Ignored

Understanding Wazuh Rootcheck

What Is Wazuh Rootcheck?

Purpose of Rootcheck

How It Detects Rootkits, Hidden Processes, and Suspicious System Modifications

Relationship Between Rootcheck and the Wazuh Agent

How Scheduled Rootcheck Scans Work

Scan Scheduling Mechanism

Default Scan Intervals

Difference Between Scheduled Scans and Manual Scans

Where Scan Results Are Stored

Symptoms That Rootcheck Scheduled Scans Are Being Ignored

Rootcheck Never Runs Automatically

No New Rootcheck Alerts

Scan Timestamps Never Change

Manual Scans Work but Scheduled Ones Do Not

Why This Narrows Down the Problem

Typical Configuration Issues

Missing Rootcheck Alerts in the Dashboard

Dashboard Indicators

Manager Logs vs. Agent Logs

Stale Rootcheck Inventory

Outdated Scan Results

Compliance and Security Risks

Common Causes of Ignored Wazuh Rootcheck Scans

Rootcheck Is Disabled

Disabled Module Configuration

Agent Configuration Errors

Incorrect Scan Frequency Settings

Invalid Frequency Values

Misconfigured Scheduling Options

Configuration Overrides

Centralized Configuration Overriding Local Settings

Agent Groups

Wazuh Agent Problems

Agent Disconnected

Agent Service Not Running

Registration Issues

Manager Communication Failures

Connectivity Problems

Authentication Issues

Firewall Restrictions

Operating System Permissions

Insufficient Privileges

Linux Permission Issues

Windows Administrative Requirements

Resource Protection Features

CPU Throttling

Performance Optimization Settings

Scan Interruptions

Step-by-Step Troubleshooting

Step 1: Verify That Rootcheck Is Enabled

Check ossec.conf

Confirm Module Status

Step 2: Review Rootcheck Configuration

Frequency

Scan Options

Directories

Ignore Lists

Step 3: Validate the Configuration

Check for XML Syntax Errors

Verify Configuration Loading

Restart Services After Changes

Step 4: Check Wazuh Agent Status

Verify the Service Is Running

Confirm Manager Connectivity

Inspect Agent Health

Step 5: Review Agent Logs

Linux Log Locations

Windows Log Locations

Rootcheck-Related Messages

Step 6: Review Manager Logs

Connection Errors

Configuration Deployment

Scheduling Messages

Step 7: Force a Manual Rootcheck Scan

How to Trigger a Manual Scan

Compare Manual vs. Scheduled Behavior

Step 8: Verify Dashboard Results

Confirm New Alerts

Frequency (`frequency`)

Scan on Startup (`scan_on_start`)

Disabled (`disabled`)

Skip NFS (`skip_nfs`)