Managing Wazuh Disk Space: Log Rotation and ISM Policies

Here's something nobody tells you when you set up Wazuh the indexer will fill your disk and never say a word about it. No warning, no alert, nothing. Just a dashboard that goes dark one day while everything else looks perfectly fine.

The Manager running, agents connected, alerts generating but the indexer had silently hit 100% disk and stopped accepting data. Days of alerts, gone. And the worst part? They had already tried to fix it. They'd set up log rotation in ossec.conf, ticked the box in their head, and moved on. What nobody told them is that the manager and the indexer are two completely separate systems and configuring one does absolutely nothing for the other.

This blog covers both. What each system does, where it stores data, how to configure it correctly, and how to verify it's actually working. All configuration is from the official Wazuh documentation.

Visit the Wazuh webpage 👉 here | Join the Wazuh Ambassador Program 👉 here

Note:
You need root or sudo access on the Wazuh server. Back up /var/ossec/etc/ossec.conf before making any changes. The ISM policy changes are made through the Wazuh dashboard — no command line needed for that part.

When Wazuh processes an alert, two things happen at the same time. The manager writes the alert to flat files on disk. Filebeat picks up those files and forwards the data to the indexer, which stores it in a searchable index. Those are two different storage locations, two different formats, and two different retention mechanisms.

Configuring one does not affect the other. The manager's log files and the indexer's indices are completely independent. If you only configure manager rotation, your indexer will still fill up. If you only configure ISM deletion, your flat files will still accumulate on disk. Both need attention.

The Wazuh manager writes alerts to two files simultaneously a plain text version and a JSON version. Both sit in the same directory:

/var/ossec/logs/alerts/alerts.log      # plain text format
/var/ossec/logs/alerts/alerts.json     # JSON format (used by Filebeat → indexer)

Wazuh rotates these automatically. It compresses the current log file, signs it with MD5, SHA1, and SHA256 checksums, and moves it into a dated directory structure. After rotation, a new empty file is created with the original name and writing continues. The archived files end up here:

/var/ossec/logs/alerts/YYYY/Mon/       # e.g. /var/ossec/logs/alerts/2026/May/

The rotation interval is controlled by the <rotate_interval> option in ossec.conf. The default behaviour rotates daily. The valid range is from 10 minutes to 1 day anything shorter than 10 minutes is rejected and will cause the manager to fail on restart.

The maximum size a log file can reach before rotation is triggered is set by <max_size>. The allowed range is from 1MiB to 1TiB.

• You don't need to SSH into the server to edit ossec.conf. You can make changes directly from the browser. Navigate to Server Management → Settings, click Edit settings, make your changes, and save. Once saved, the dashboard will prompt you to restart the manager right there — no terminal required.

• If you prefer the terminal, the same file can be edited directly on the server:

  sudo nano /var/ossec/etc/ossec.conf

  Find the <global> section and add or update these options:

  <ossec_config>
   <global>
      <!-- rotate alert log files every 24 hours -->
     <rotate_interval>1d</rotate_interval>
      <!-- also rotate if a single file reaches 500MB -->
     <max_size>500MiB</max_size>
      <!-- keep JSON output enabled (required for Filebeat → indexer pipeline) -->
     <jsonout_output>yes</jsonout_output>
     <alerts_log>yes</alerts_log>
    </global>
  </ossec_config>

• Apply the change:

  sudo systemctl restart wazuh-manager
  sudo systemctl status wazuh-manager

• Viewing the manager logs from the dashboard

  The manager logs are visible directly from the Wazuh dashboard — you don't need to SSH in and tail a file. Navigate to Server Management → Logs to see real-time manager log output including rotation events, errors, and warnings. This is useful for confirming that rotation is working and spotting any issues after a config change.

  

Separate from alerts, Wazuh can also log every single event it receives including events that don't trigger any rule into archive files at /var/ossec/logs/archives/. This is controlled by <logall> and <logall_json> in ossec.conf. By default both are disabled because archive logging consumes significant disk space it stores everything, not just alerts.

<global>
 <logall>no</logall>        <!-- plain text archives -->
 <logall_json>no</logall_json>   <!-- JSON archives(needed if you want archive index in dashboard) -->
</global>

Note:
The Wazuh documentation states that archives are disabled by default because they store logs indefinitely on the Wazuh server. If you enable them, the /var/ossec/logs/archives/ directory will grow without limit. Only enable this if you have a disk monitoring and cleanup plan in place.

Verify the storage utilization of Wazuh alert and archive logs and review the alert log files and their sizes.

du -sh /var/ossec/logs/alerts/
du -sh /var/ossec/logs/archives/
ls -lh /var/ossec/logs/alerts/

Every day, Wazuh automatically creates a new index in the indexer named wazuh-alerts-4.x-YYYY.MM.DD. That index collects all the alerts for that day. At midnight, a new one is created and the old one stays exactly where it is forever, until you delete it manually or set up a policy that does it for you.

There is no automatic cleanup on the indexer side out of the box. Nothing deletes old indices. They accumulate silently until the disk fills, at which point the indexer stops accepting new data and your dashboard goes dark.

The solution is an ISM (Index State Management) policy. ISM is the indexer's built-in policy engine you define rules like "delete any index older than 90 days" and it handles the rest automatically.

Navigate to the ISM Policies page in the dashboard and click Create policy. Select Visual editor.
Give the policy a name something like  wazuh-alerts-retention-90d . Then configure it:
Under States, you'll start with one state call it  hot . This represents the active phase where the index is being written to and searched. Add a transition from this state with the condition: Minimum index age set to  90d . Point that transition to a new state called  delete .
In the  delete  state, add an action: Delete. No further transitions needed.
If you prefer to write it as JSON directly, click JSON editor and paste this:

{
  "policy": {
   "description": "Delete wazuh-alerts indices older than 90 days",
   "default_state": "hot",
    "states": [
      {
        "name": "hot",
       "actions": [],
       "transitions": [
          {
           "state_name": "delete",
           "conditions": {
             "min_index_age": "90d"
            }
          }
        ]
      },
      {
        "name": "delete",
       "actions": [
          {
           "delete": {}
          }
        ],
       "transitions": []
      }
    ],
   "ism_template": [
      {
       "index_patterns": ["wazuh-alerts-4.x-*"],
       "priority": 100
      }
    ]
  }
}

Note:
The ism_template block at the bottom automatically applies this policy to any new index matching wazuh-alerts-4.x-*. This means every new daily index gets the policy assigned automatically you don't need to manually attach it each time a new index is created.

The ism_template only applies to new indices created after the policy exists. Your existing indices — everything already sitting in the indexer need to be attached manually. Go to Index Management → Indexes, select the indices you want to manage, and click Apply policy.

After applying, click into any index and check the Policy tab. It should show the policy name, current state (hot), and the last time ISM evaluated the index. ISM checks indices every 5 minutes by default.

Note:
90 days is a common starting point but your environment may need more or less. PCI DSS requires 12 months of log availability. GDPR doesn't specify a retention period but expects proportionality. Check your compliance requirements before deciding on the value. Change 90d in the JSON to whatever fits 30d, 180d, 365d.

The ISM policy takes care of automatic deletion, but it's worth knowing how to check the current state manually especially on a setup where you've just applied a policy for the first time and want to see what's actually consuming space.

• FROM THE DASHBOARD

  The Index Management page shows each index with its size and document count. Sort by size to quickly see which indices are the largest.

  

• FROM THE COMMAND LINE

  Total disk usage of the indexer data directory
  du -sh /var/lib/wazuh-indexer/
  # Check available disk on the partition
  df -h /var/lib/wazuh-indexer/

  Note:
  When the indexer partition hits 100%, the indexer sets all indices to read-only automatically to protect data integrity. New alerts from Filebeat start failing silently. Your dashboard stops updating. The manager keeps running and alerts keep generating but none of it reaches the indexer. This is the scenario the ISM policy prevents.

The manager writes alerts to /var/ossec/logs/alerts/alerts.json . Filebeat reads that file and forwards the data to the indexer. The indexer stores it in a daily wazuh-alerts-4.x-YYYY.MM.DD  index. These are three separate steps — and the data lives independently in each location.

Deleting an old index from the indexer via ISM does NOT delete the corresponding flat files from the manager. If you have 90-day retention on the indexer, you'll have no alerts older than 90 days in the dashboard — but the rotated, compressed flat files in /var/ossec/logs/alerts/ may still be sitting on disk, depending on how long the manager keeps them.

The reverse is also true — cleaning up old log files on the manager filesystem doesn't touch anything in the indexer.

So the complete picture is:

After setting everything up, here's a quick checklist to confirm both systems are actually doing what you expect.

• MANAGER SIDE VERIFY ROTATION IS WORKING

# List rotated alert files from this month
ls -lh /var/ossec/logs/alerts/2026/May/
# Confirm ossec.conf has rotation settings applied
grep -A5 "rotate_interval\|max_size" /var/ossec/etc/ossec.conf
# Check manager is running cleanly after config change
sudo systemctl status wazuh-manager 

• INDEXER SIDE VERIFY ISM POLICY IS ATTACHED AND EVALUATING

  The response shows each index, the policy attached to it, the current state, and when ISM last evaluated it. If you see "policy_id": "wazuh-alerts-retention-90d" against your indices, the policy is attached and running.

  

Two systems. Two configs. Neither knows about the other. Once you've got the ISM policy in place and rotation set in  ossec.conf , you're covered on both sides and you won't be the person debugging a silent indexer at 2am wondering why the dashboard stopped showing alerts three days ago.
The ISM policy is the more important one to get right. The manager's flat file rotation has sensible defaults and won't break your production setup. The indexer will silently fill your disk without any warning if you leave it alone