As your Wazuh deployment grows, so does the volume of security events it generates.
Authentication logs, file integrity monitoring alerts, vulnerability scan results, endpoint telemetry, and network events quickly accumulate into millions of documents stored within the Wazuh Indexer.
Without a structured lifecycle strategy, these indexes consume valuable disk space, degrade search performance, and increase operational complexity.
This is where Wazuh Index State Management (ISM) becomes essential.
Index State Management (ISM) is an OpenSearch feature that automatically manages indexes throughout their lifecycle using predefined policies.
Instead of manually deleting old indexes or constantly monitoring disk usage, administrators can define rules that transition indexes through different states based on age, size, or other conditions.
ISM can automatically roll over active indexes, optimize older ones, move them to lower-cost storage, and eventually delete them when they are no longer needed.
For security operations teams, automating index management provides several important benefits:
- Prevents storage from filling unexpectedly
- Improves dashboard responsiveness by limiting active indexes
- Reduces administrative effort
- Ensures retention policies are enforced consistently
- Helps maintain a healthy and scalable Wazuh deployment
Whether you’re managing a small lab environment or an enterprise SIEM collecting billions of events, implementing ISM is one of the most effective ways to keep your Wazuh infrastructure efficient and reliable.
In this guide, you’ll learn:
- How Wazuh Index State Management works
- How ISM integrates with the Wazuh Indexer
- The lifecycle states used by OpenSearch
- How to create and apply ISM policies
- Best practices for retention, rollover, and deletion
- Common mistakes to avoid when managing Wazuh indexes
You’ll also learn how ISM complements broader index optimization strategies discussed in How to Design a Wazuh OpenSearch Shard Allocation Strategy and How to Configure Wazuh Log Retention.
For readers unfamiliar with the underlying storage engine, OpenSearch’s official documentation provides an excellent overview of Index State Management.
What Is Wazuh Index State Management (ISM)?
Wazuh Index State Management (ISM) is the process of automatically controlling how indexes are created, maintained, optimized, and eventually deleted throughout their lifecycle.
Rather than relying on administrators to manually monitor index growth, ISM applies predefined policies that execute actions when specific conditions are met.
Since the Wazuh Indexer is built on OpenSearch, it inherits OpenSearch’s native ISM framework.
Every security event collected by Wazuh is stored inside OpenSearch indexes, making ISM a core feature for maintaining long-term performance and storage efficiency.
Definition of Index State Management
Index State Management is a policy-driven lifecycle automation framework that manages indexes based on configurable states and transitions.
Each policy consists of one or more states such as:
- Hot (actively receiving data)
- Warm (less frequently accessed)
- Cold (archival storage)
- Delete (remove permanently)
Within each state, OpenSearch performs automated actions such as:
- Rolling over indexes
- Reducing replica counts
- Allocating indexes to different nodes
- Force-merging segments
- Applying read-only settings
- Deleting expired indexes
Instead of scheduling manual maintenance tasks, administrators simply attach an ISM policy to an index pattern and allow OpenSearch to handle the lifecycle automatically.
How ISM Works Within OpenSearch
OpenSearch continuously evaluates indexes against the conditions defined in an ISM policy.
A typical lifecycle might look like this:
- A new Wazuh alerts index is created.
- The index remains in the Hot state while actively receiving security events.
- After reaching a specified age or size, OpenSearch automatically rolls over to a new index.
- Older indexes transition to a Warm state where they are optimized for storage efficiency.
- After the retention period expires, OpenSearch deletes the index automatically.
This event-driven automation eliminates the need for scheduled scripts or manual cleanup.
According to the OpenSearch documentation, ISM policies are evaluated regularly by the background policy engine, allowing lifecycle transitions to occur without administrator intervention.
Difference Between Manual Index Management and Automated Lifecycle Policies
Without ISM, administrators are responsible for tasks such as:
- Monitoring index sizes
- Creating new indexes
- Deleting old indexes
- Managing disk utilization
- Optimizing search performance
- Enforcing retention requirements
These manual processes are time-consuming and prone to human error.
With ISM, these operations become automated through lifecycle policies.
| Manual Management | Index State Management |
|---|---|
| Manual index cleanup | Automatic deletion |
| Manual rollover | Automatic rollover |
| Constant storage monitoring | Policy-driven storage optimization |
| Scheduled maintenance scripts | Built-in lifecycle automation |
| Inconsistent retention | Consistent policy enforcement |
| Higher administrative workload | Minimal ongoing management |
For environments producing continuous security telemetry, automation significantly reduces operational overhead while improving reliability.
Relationship Between Wazuh Indexer and OpenSearch ISM
The Wazuh Indexer is an OpenSearch-based search and analytics engine responsible for storing all indexed security data.
Because Wazuh Indexer uses OpenSearch internally, ISM is not a separate Wazuh feature, it is an OpenSearch capability used to manage Wazuh indexes.
This means administrators can apply ISM policies to indexes such as:
wazuh-alerts-*wazuh-archives-*wazuh-monitoring-*- Custom security indexes
Understanding this relationship is important because many performance tuning recommendations for OpenSearch also apply directly to Wazuh deployments.
Readers interested in index architecture should also see How to Build a Wazuh Indexer Cluster and The Complete Wazuh Cluster Architecture Guide.
Why Use Index State Management in Wazuh?
Security monitoring platforms continuously ingest massive amounts of log data.
Without lifecycle automation, storage usage grows indefinitely, queries become slower, and administrators spend increasing amounts of time performing maintenance.
Index State Management addresses these challenges by automating the lifecycle of every Wazuh index.
Reduce Storage Costs
Security logs accumulate rapidly.
A medium-sized environment can generate hundreds of gigabytes, or even terabytes, of indexed data each month.
Rather than storing every index on expensive high-performance disks, ISM enables organizations to:
- Delete obsolete indexes automatically
- Move older data to lower-cost storage tiers
- Reduce replica counts for archival indexes
- Optimize storage utilization
These capabilities help organizations significantly lower infrastructure costs while preserving data for the required retention period.
Improve Search Performance
Search performance depends heavily on the number and size of active indexes.
When clusters retain thousands of aging indexes, search operations require additional resources, increasing latency for dashboards and investigations.
ISM improves search responsiveness by:
- Keeping active indexes appropriately sized
- Rolling over large indexes automatically
- Removing obsolete indexes
- Optimizing older indexes through force merge operations
This allows investigators to query recent security events more efficiently while historical data remains available when needed.
Automate Index Lifecycle Management
One of ISM’s greatest advantages is complete lifecycle automation.
Instead of relying on cron jobs or manual maintenance windows, administrators define policies once and allow OpenSearch to enforce them automatically.
Typical automated actions include:
- Rollover after 50 GB
- Transition after 30 days
- Force merge after rollover
- Reduce replicas after 60 days
- Delete after 180 days
Automation reduces configuration drift and ensures every index follows the same lifecycle.
Prevent Disk Space Exhaustion
One of the most common causes of Wazuh Indexer failures is running out of available disk space.
When storage reaches critical thresholds, OpenSearch may:
- Block writes
- Reject new indexes
- Mark shards as read-only
- Trigger cluster health warnings
ISM helps prevent these situations by continuously removing expired indexes before storage reaches dangerous levels.
If you’re already experiencing storage-related issues, see How to Fix a Yellow Cluster Status in Wazuh Indexer and How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes.
Simplify Compliance Retention Policies
Many regulatory frameworks require organizations to retain security logs for specific periods.
Examples include:
- PCI DSS
- HIPAA
- SOX
- GDPR
- ISO 27001
Rather than manually tracking retention dates, ISM enforces policies consistently across every index.
For example:
- Keep authentication logs for 365 days
- Retain vulnerability scan results for one year
- Delete endpoint telemetry after 180 days
Automated enforcement reduces compliance risk while eliminating manual record management.
The U.S. National Institute of Standards and Technology (NIST) emphasizes the importance of establishing and enforcing log retention policies as part of an organization’s security monitoring program.
Reduce Administrative Overhead
Manual index management becomes increasingly difficult as environments scale.
Administrators no longer need to:
- Monitor every index daily
- Schedule cleanup jobs
- Delete indexes manually
- Estimate storage consumption continuously
- Create custom maintenance scripts
Instead, lifecycle policies execute automatically in the background.
This allows security teams to spend more time investigating threats and improving detection capabilities rather than performing routine maintenance.
As OpenSearch creator Shay Banon has long advocated through the evolution of Elasticsearch and OpenSearch ecosystems, automating operational workflows is a key principle for building scalable, resilient search infrastructures.
Automating index lifecycle management follows this principle by reducing repetitive operational tasks while improving cluster stability.
How Wazuh Indexes Are Organized
Before configuring Index State Management (ISM), it’s important to understand how Wazuh organizes its indexed data.
Different types of information are stored in separate indexes, allowing administrators to apply lifecycle policies based on the value and retention requirements of each dataset.
Rather than treating all security data equally, Wazuh separates alerts, archived logs, monitoring information, and internal operational data into distinct index patterns.
This makes it possible to retain critical security alerts for longer periods while deleting less valuable operational data sooner.
Alerts Indexes
Alerts indexes contain the security events generated after Wazuh processes incoming logs through its decoders and rules.
These indexes typically include:
- Authentication failures
- Malware detections
- File Integrity Monitoring (FIM) alerts
- Vulnerability detection events
- Active Response executions
- Compliance violations
- Threat intelligence matches
- Custom detection rule alerts
For most deployments, alerts indexes are the primary source of information used during threat hunting, incident response, and dashboard visualization.
Because alerts are accessed frequently, they generally remain in the Hot state longer than other indexes before transitioning to less expensive storage tiers.
If you’re unfamiliar with how alerts are generated, see How to Create Custom Detection Rules in Wazuh (With Examples) and How to Test Wazuh Rules.
Archives Indexes
Archive indexes store the original log events received by Wazuh before correlation and rule evaluation.
Unlike alerts, archived logs often contain:
- Raw syslog messages
- Windows Event Logs
- Linux audit logs
- Application logs
- Firewall logs
- Cloud service logs
Since archive data is significantly larger than alert data, it usually consumes the majority of available storage in large deployments.
Many organizations apply shorter retention periods to archive indexes or transition them to lower-cost storage after a few weeks.
For organizations using archives for forensic investigations, retention policies should align with business and regulatory requirements.
Monitoring Indexes
Monitoring indexes collect operational metrics about the Wazuh platform itself.
Examples include:
- Cluster health
- Node statistics
- JVM usage
- CPU utilization
- Memory consumption
- Disk usage
- Indexing performance
These indexes help administrators monitor the health of the Wazuh Indexer cluster and troubleshoot infrastructure issues.
Since monitoring data loses value relatively quickly, organizations often configure shorter retention periods than those used for security alerts.
Readers interested in performance tuning should also review Step-by-Step Wazuh Manager Scaling Guide and How to Build a Wazuh Indexer Cluster.
Statistics and Internal Indexes
Wazuh and OpenSearch also maintain several internal indexes used for platform functionality.
These may include:
- Dashboard configuration data
- Saved searches
- Visualizations
- User settings
- Security configuration
- Index management metadata
- System statistics
Unlike alerts or archives, these indexes should generally not be managed with aggressive deletion policies.
Accidentally deleting internal indexes can lead to:
- Missing dashboards
- Lost visualizations
- Broken authentication
- Cluster management issues
Always verify an index’s purpose before applying lifecycle policies.
Daily vs. Rollover Index Patterns
Historically, many Wazuh deployments created a new index every day using date-based naming conventions such as:
wazuh-alerts-4.x-2026.07.24This approach simplifies retention because administrators can delete indexes based on the date embedded in the name.
Modern OpenSearch deployments increasingly favor rollover indexes, where a new index is created only after meeting predefined thresholds, such as:
- Maximum age
- Maximum size
- Maximum document count
For example:
wazuh-alerts-000001
wazuh-alerts-000002
wazuh-alerts-000003Rollover patterns generally produce more consistent shard sizes, improve cluster balance, and work seamlessly with ISM policies.
For additional guidance on shard sizing, see How to Design a Wazuh OpenSearch Shard Allocation Strategy.
Index Templates and Aliases
Index templates ensure that newly created indexes inherit consistent settings.
Templates typically define:
- Number of primary shards
- Replica count
- Index mappings
- Analysis settings
- ISM policy assignment
- Rollover alias
Aliases provide a stable name that applications query regardless of which physical index currently receives writes.
For example:
Alias:
wazuh-alerts
Current write index:
wazuh-alerts-000014When a rollover occurs, OpenSearch automatically updates the alias to point to the new write index, allowing Wazuh to continue indexing data without configuration changes.
OpenSearch recommends using templates together with rollover aliases because they enable fully automated lifecycle management.
How Wazuh Index State Management Works
Index State Management operates through a series of policies that evaluate indexes and automatically perform lifecycle operations based on predefined rules.
Rather than relying on scheduled scripts or manual administration, ISM continuously checks indexes and determines whether they should transition to a new lifecycle state.
Understanding the core components of ISM makes policy creation much easier.
States
A state represents a stage in an index’s lifecycle.
Common lifecycle states include:
- Hot
- Warm
- Cold
- Delete
Each state serves a specific purpose.
For example:
| State | Purpose |
|---|---|
| Hot | Active indexing and frequent searches |
| Warm | Less frequent access with optimized storage |
| Cold | Long-term retention on lower-cost infrastructure |
| Delete | Permanent removal after retention expires |
An index remains in a state until its transition conditions are satisfied.
Actions
Actions define the operations OpenSearch performs while an index resides in a particular state.
Common ISM actions include:
- Rollover
- Read-only
- Force merge
- Replica reduction
- Allocation
- Notification
- Snapshot (if integrated with snapshot workflows)
- Delete
For example, a Hot state might:
- Accept writes
- Roll over after 50 GB
A Warm state might:
- Make the index read-only
- Force merge segments
- Reduce replicas
Each action is executed automatically according to the assigned policy.
Conditions
Conditions determine when actions or transitions occur.
Common conditions include:
- Index age
- Index size
- Document count
- Time since rollover
Examples:
- Older than 30 days
- Larger than 50 GB
- More than 25 million documents
Conditions allow lifecycle decisions to adapt dynamically as data grows.
Transitions
Transitions move an index from one state to another once defined conditions are met.
For example:
Hot
↓ after 30 days
Warm
↓ after 90 days
Cold
↓ after 365 days
DeleteBecause transitions occur automatically, administrators rarely need to intervene after the policy is deployed.
Policies
A policy combines states, actions, and transitions into a complete lifecycle definition.
For example, a Wazuh alerts policy might specify:
- Hot for 30 days
- Warm for 90 days
- Cold until one year
- Delete after 365 days
Policies can be attached to:
- Individual indexes
- Index patterns
- Index templates
Organizations often create separate policies for alerts, archives, and monitoring indexes to reflect different retention requirements.
Index Templates
Index templates automatically apply ISM policies to newly created indexes.
Without templates, administrators would need to attach lifecycle policies manually every time a new index is created.
Templates ensure consistency by automatically assigning:
- Mappings
- Settings
- Shard configuration
- Replica configuration
- ISM policy
- Rollover alias
This automation becomes especially valuable in environments where new indexes are created frequently.
Rollovers
Rollovers create a new write index when predefined thresholds are reached.
Common rollover triggers include:
- Maximum size
- Maximum age
- Maximum document count
Instead of allowing one index to grow indefinitely, OpenSearch creates a fresh index while applications continue writing through an alias.
Benefits include:
- More consistent shard sizes
- Faster searches
- Better resource utilization
- Reduced cluster imbalance
The OpenSearch project recommends rollover-based index management for time-series workloads because it produces more predictable index sizes and improves lifecycle automation.
Deletion
The final stage of most lifecycle policies is automatic deletion.
Once an index exceeds the configured retention period, ISM permanently removes it without administrator intervention.
Automatic deletion helps:
- Reclaim disk space
- Prevent storage exhaustion
- Maintain healthy clusters
- Enforce retention policies consistently
Before enabling automatic deletion, organizations should verify that important indexes have been backed up using snapshots.
Readers responsible for long-term data retention should also review How to Configure Wazuh Log Retention.
Prerequisites
Before implementing Index State Management, verify that your Wazuh environment is properly prepared.
While configuring ISM is straightforward, applying lifecycle policies without proper planning can result in unintended data loss or operational issues.
Supported Wazuh and OpenSearch Versions
Ensure your Wazuh deployment includes a version of the Wazuh Indexer that supports OpenSearch Index State Management.
Older Elasticsearch-based Wazuh releases used Index Lifecycle Management (ILM), while current OpenSearch-based releases use ISM.
Always confirm compatibility with the version of Wazuh and OpenSearch you are running before creating policies.
The official Wazuh documentation includes version compatibility details for supported releases.
Administrative Access to Wazuh Dashboard or OpenSearch API
Creating and managing ISM policies requires administrative privileges.
You should have access to either:
- The Wazuh Dashboard’s Index Management interface
- The OpenSearch REST API
- Command-line tools capable of sending authenticated API requests
Most lifecycle management tasks, including creating policies, attaching templates, and monitoring execution, can be completed through either interface.
Existing Wazuh Indexer Cluster
ISM policies are applied to indexes stored in the Wazuh Indexer.
Before proceeding, verify that:
- The Indexer cluster is healthy
- All nodes are online
- Cluster status is Green (or Yellow if appropriate)
- Index creation is functioning normally
If your cluster already reports health issues, resolve them before deploying lifecycle policies.
See How to Fix a Yellow Cluster Status in Wazuh Indexer and The Complete Wazuh Cluster Architecture Guide..
Snapshot Strategy Before Deleting Indexes
Automatic deletion should never be enabled without first establishing a backup strategy.
Before indexes reach the Delete state, consider:
- Creating scheduled snapshots
- Testing snapshot restoration
- Defining recovery procedures
- Verifying backup retention periods
The OpenSearch documentation recommends snapshots as the primary disaster recovery mechanism before permanently deleting index data.
Understanding of Index Patterns
Finally, administrators should understand how index patterns map to different categories of Wazuh data.
Before applying policies, identify:
- Alert indexes
- Archive indexes
- Monitoring indexes
- Internal system indexes
- Custom application indexes
Applying the wrong policy to an index pattern can lead to premature deletion of critical data or retention of unnecessary information.
Taking time to inventory your index patterns ensures that each dataset receives a lifecycle policy aligned with its operational and compliance requirements.
Be First to Comment