How to Fix circuit_breaking_exception Data Overloads in Wazuh Indexer

The circuit_breaking_exception error is one of the most common memory-related problems administrators encounter when managing a Wazuh Indexer cluster.

Although the message may appear alarming, it is actually a built-in safety mechanism inherited from OpenSearch that prevents the indexer from exhausting Java heap memory and crashing.

Instead of allowing a request to consume all available memory, the circuit breaker rejects the operation before it can destabilize the cluster.

In Wazuh environments, this error typically appears while indexing large volumes of security events, executing resource-intensive searches, or processing dashboards that require complex aggregations.

As organizations add more monitored endpoints, enable additional detection modules, or retain data for longer periods, memory consumption increases significantly.

Without sufficient heap memory or optimized workloads, the indexer begins rejecting requests with a circuit_breaking_exception.

Administrators experiencing this issue often notice symptoms such as:

• Failed dashboard searches
• Missing search results or incomplete visualizations
• Slow query performance
• Bulk indexing failures
• API requests returning HTTP 429 or 503 errors
• Repeated circuit_breaking_exception messages in Indexer logs
• Increased garbage collection (GC) activity and elevated JVM memory usage

Because the error is preventative rather than catastrophic, it provides an opportunity to resolve memory bottlenecks before they become service outages.

In this guide, you’ll learn:

• What the Wazuh Indexer circuit breaker actually does
• Why circuit_breaking_exception occurs
• The most common underlying causes
• How to identify the exact bottleneck
• Proven methods to eliminate the error and improve cluster stability
• Best practices to prevent memory overloads as your Wazuh deployment grows

Understanding the root cause is essential because simply increasing heap memory is often only a temporary fix.

In many cases, inefficient queries, excessive shard counts, or oversized indexing operations are the real source of the problem.

Understanding the Wazuh Indexer Circuit Breaker

What Is the Circuit Breaker?

The Wazuh Indexer is built on OpenSearch, which includes several circuit breaker mechanisms designed to protect JVM heap memory from becoming exhausted.

Instead of allowing operations to consume unlimited memory, these breakers estimate how much memory an operation will require.

If the projected usage exceeds configured limits, OpenSearch rejects the request before it can destabilize the node.

This design helps maintain cluster availability even during periods of heavy indexing or complex search activity.

Purpose of Memory Protection

Unlike CPU utilization, heap memory is a finite resource that cannot be overcommitted safely. Once heap memory is exhausted, Java begins aggressive garbage collection.

If memory cannot be reclaimed, the JVM eventually throws an out-of-memory error, which can terminate the Indexer process entirely.

Circuit breakers reduce this risk by rejecting individual operations before they consume excessive heap memory.

According to the OpenSearch documentation, circuit breakers estimate memory requirements rather than measuring exact allocations, allowing them to proactively prevent memory exhaustion before requests are executed.

Preventing JVM Out-of-Memory Crashes

Without circuit breakers, a single expensive aggregation or massive bulk indexing request could allocate gigabytes of heap memory within seconds.

Instead of allowing that to happen, OpenSearch returns an error similar to:

circuit_breaking_exception
[parent] Data too large, data for [request] would be larger than limit

Although the request fails, the node remains operational.

This behavior is considerably preferable to a JVM crash, which would require node recovery and shard reallocation.

Relationship between OpenSearch and Wazuh Indexer

Wazuh Indexer is based on OpenSearch, meaning nearly all memory management behavior, including heap allocation, garbage collection, shard management, and circuit breakers, is inherited directly from OpenSearch.

As a result, many OpenSearch tuning recommendations also apply to Wazuh Indexer.

Related Guide: How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes

Administrators troubleshooting memory issues should therefore understand both Wazuh-specific workloads and the underlying OpenSearch architecture.

How Circuit Breakers Work

OpenSearch includes several independent circuit breakers that protect different types of memory allocations.

Each breaker tracks estimated memory usage for specific operations.

Parent Circuit Breaker

The parent breaker monitors overall heap consumption across all breakers.

If the total estimated memory exceeds its configured threshold (typically around 95% of heap), the parent breaker rejects additional requests.

This is the breaker responsible for most circuit_breaking_exception errors seen in Wazuh deployments.

Field Data Circuit Breaker

Field data is generated when OpenSearch loads field values into memory for sorting, scripting, or aggregations.

If field data begins consuming excessive heap, this breaker prevents additional allocations.

Clusters using improperly mapped text fields often trigger this breaker.

Request Circuit Breaker

The request breaker estimates memory required for individual search operations.

Large aggregations, nested queries, wildcard searches, and high-cardinality analytics frequently consume significant temporary memory.

Rather than allowing these requests to monopolize heap resources, the breaker rejects them before execution.

In-Flight Requests Breaker

This breaker tracks memory used by currently active network requests that have not yet completed.

High volumes of simultaneous API requests or large search responses can increase in-flight memory usage dramatically.

Busy dashboard users or automation platforms commonly contribute to this type of pressure.

Accounting Breaker

The accounting breaker monitors persistent internal memory allocations used by OpenSearch components.

Unlike temporary search memory, these allocations remain reserved for longer periods.

This breaker helps ensure that long-lived objects do not silently consume excessive heap capacity.

Why Wazuh Triggers circuit_breaking_exception

While circuit breakers exist to protect memory, certain workloads commonly push Wazuh Indexer beyond safe operating limits.

Heap Memory Exhaustion

The most common cause is simply insufficient JVM heap memory.

As monitored endpoints increase, more alerts, logs, vulnerability data, and FIM events are indexed simultaneously.

If available heap cannot accommodate these workloads, circuit breakers activate.

Large Search Requests

Security analysts often execute searches covering weeks or months of historical data.

Wide time ranges increase:

• Documents scanned
• Buckets created
• Aggregation memory
• Query execution time

These searches may exceed the request breaker limits even on otherwise healthy clusters.

Heavy Aggregations

Dashboards frequently calculate:

• Top IP addresses
• Alert counts
• Severity distributions
• Geographic statistics
• Event timelines

Aggregations require additional heap memory because OpenSearch must build in-memory structures before returning results.

The larger the dataset, the greater the memory requirements.

Excessive Indexing Activity

Rapid ingestion from thousands of Wazuh agents can temporarily overwhelm available heap.

Examples include:

• Endpoint reconnect storms
• Large Windows Event Log bursts
• Mass vulnerability scans
• File Integrity Monitoring spikes

These events create indexing backlogs that increase memory pressure.

Related Guide: Why Is Wazuh Using High CPU? Troubleshooting Guide

Large Bulk Imports

Bulk indexing improves throughput but increases temporary memory usage because many documents must be processed simultaneously.

Oversized bulk requests can exceed heap limits before indexing completes.

Experienced OpenSearch engineers generally recommend keeping bulk requests reasonably sized and benchmarking batch sizes rather than assuming larger batches always improve performance.

Common Causes of circuit_breaking_exception

Insufficient JVM Heap Allocation

One of the most frequent causes of circuit_breaking_exception is simply allocating too little heap memory to the Wazuh Indexer.

Every search, aggregation, indexing request, and background process relies on JVM heap.

If the heap is undersized, even moderate workloads can exceed memory limits and trigger the circuit breaker.

Default Heap Limitations

Many deployments begin with the default JVM heap configuration, which may be sufficient for evaluation environments but often proves inadequate for production clusters with thousands of monitored endpoints.

As log volume grows, so does the amount of memory required for indexing buffers, query execution, field data, and caching.

Administrators who never revisit the default heap settings frequently encounter memory-related exceptions as their deployment scales.

Improper JVM Sizing

Allocating too little heap leaves insufficient memory for OpenSearch operations, while allocating too much can reduce the operating system’s filesystem cache and negatively affect overall performance.

OpenSearch and many JVM tuning experts commonly recommend setting the heap to approximately 50% of available system RAM, while avoiding allocations larger than roughly 32 GB to preserve compressed object pointers (compressed OOPs) and maintain JVM efficiency.

Excessive Indexing Throughput

Heavy ingestion rates can temporarily consume large amounts of heap memory before data is written to disk.

Large Agent Deployments

Organizations monitoring thousands of endpoints generate a continuous stream of security events.

As the number of agents increases, indexing queues, segment creation, and memory buffers all grow proportionally.

Log Ingestion Spikes

Unexpected bursts of activity, such as malware outbreaks, authentication storms, or widespread configuration changes, can generate millions of events in a short period.

These spikes increase memory usage dramatically and may trigger the parent circuit breaker before indexing catches up.

Bulk Indexing Operations

Bulk requests improve indexing efficiency by reducing network overhead, but extremely large batches require additional heap to process every document before committing them to storage.

Oversized batches can therefore exhaust available heap even if average indexing rates are otherwise manageable.

Expensive Search Queries

Search performance has a direct impact on heap consumption because OpenSearch builds temporary in-memory data structures while executing queries.

Wide Wildcard Searches

Queries such as:

*

or

error*

across many indices force the indexer to examine significantly more terms than targeted searches.

As index sizes grow, wildcard queries become increasingly memory intensive.

Deep Pagination

Retrieving results far beyond the first few pages requires OpenSearch to maintain large result sets in memory.

Requests using very high from values or excessively large page sizes can consume substantial heap.

Large Aggregations

Aggregations that calculate statistics across millions of documents require OpenSearch to build buckets and intermediate data structures in memory.

The larger the dataset or the higher the field cardinality, the greater the memory requirements.

Complex Dashboards

Dashboards that execute multiple visualizations simultaneously may launch dozens of searches at once.

Each visualization consumes memory independently, and collectively they can exceed available heap during peak usage.

High Field Data Memory Usage

Field data is another common source of memory pressure.

Sorting and Aggregating on Text Fields

Sorting or aggregating directly on analyzed text fields forces OpenSearch to load large amounts of field data into heap memory.

Using keyword fields instead is generally much more efficient.

Unoptimized Mappings

Improper index mappings can dramatically increase heap consumption during searches.

Fields that should be stored as keywords, numerics, or dates may instead be indexed as analyzed text, resulting in unnecessary field data allocations and higher memory usage.

Too Many Concurrent Requests

Even well-optimized queries can overwhelm a cluster when too many execute simultaneously.

Multiple Dashboards

Several analysts loading dashboards at the same time can generate dozens of concurrent searches, each competing for heap memory.

Automated API Queries

Monitoring platforms, scripts, and integrations often poll the Wazuh API or OpenSearch APIs at frequent intervals. Poorly scheduled automation can create sustained memory pressure throughout the day.

Parallel Searches

Applications that execute many parallel searches to improve responsiveness may unintentionally overload the request circuit breaker if aggregate memory usage exceeds configured limits.

Oversized Bulk Requests

Large bulk operations are another frequent contributor to circuit_breaking_exception.

Bulk Indexing Exceeding Available Heap

Submitting extremely large bulk requests requires OpenSearch to hold many documents in memory while validating, parsing, and indexing them. If the batch size exceeds available heap, the request is rejected before completion.

Large Ingestion Batches

Rather than sending hundreds of thousands of documents in one request, smaller batches typically produce more stable memory utilization while maintaining high indexing throughput.

Cluster Memory Pressure

Sometimes the issue is not a single request but the cumulative memory demands of the cluster.

High Shard Count

Each shard consumes memory for metadata, caches, and background processes. Excessive shard counts reduce the heap available for indexing and search operations, increasing the likelihood of circuit breaker exceptions.

Too Many Open Indices

Keeping numerous historical indices open simultaneously increases heap usage even when those indices are rarely queried. Closing or deleting unused indices can significantly reduce memory consumption.

Background Merge Operations

OpenSearch continuously merges index segments in the background to improve search performance.

During periods of heavy indexing, merge operations compete with user queries for available heap, contributing to temporary memory pressure and increasing the likelihood of circuit_breaking_exception errors.

How to Diagnose the Problem

Before increasing heap memory or modifying your cluster configuration, identify what is actually triggering the circuit_breaking_exception.

The error is often a symptom rather than the root cause.

A methodical diagnosis helps determine whether the problem stems from insufficient memory, inefficient queries, excessive indexing activity, or an overloaded cluster.

Review Wazuh Indexer Logs

The first step is examining the Indexer logs, which usually contain detailed information about the rejected request.

Identifying circuit breaker exceptions

Search the Indexer logs for entries containing:

circuit_breaking_exception

or

[parent] Data too large

Depending on your installation, the logs are commonly located under:

/var/log/wazuh-indexer/

Look for repeated failures rather than isolated incidents. Frequent circuit breaker exceptions typically indicate an ongoing memory bottleneck instead of a temporary workload spike.

Understanding Error Details

A typical error includes valuable diagnostic information such as:

• Which circuit breaker was triggered
• Estimated memory required
• Current heap usage
• Configured breaker limit
• Type of request being executed

For example:

[parent] Data too large,
data for [aggregation] would be larger than limit

This immediately indicates that an aggregation query, not indexing, is exhausting heap memory.

Understanding exactly which operation failed greatly narrows the troubleshooting process.

Check JVM Heap Usage

Heap utilization is usually the most important metric when diagnosing this problem.

Monitor Heap Utilization

Monitor JVM heap usage over time instead of looking at a single snapshot.

Warning signs include:

• Heap consistently above 80%
• Frequent spikes above 90%
• Memory failing to recover after garbage collection
• Heap steadily increasing throughout the day

If heap remains near the parent circuit breaker threshold, additional requests are much more likely to be rejected.

Garbage Collection Indicators

Frequent or lengthy garbage collection (GC) cycles often indicate heap pressure.

Symptoms include:

• Increased GC frequency
• Long GC pause times
• CPU spikes caused by garbage collection
• Heap recovering only slightly after GC completes

OpenSearch engineers generally recommend monitoring GC behavior because excessive garbage collection often appears well before circuit breaker exceptions become frequent.

Inspect Cluster Health

Memory issues frequently affect the overall health of the Indexer cluster.

Node Status

Verify that every Indexer node is:

• Online
• Responding normally
• Participating in the cluster
• Not restarting unexpectedly

A missing node places additional indexing and search load on the remaining nodes, increasing memory consumption.

Memory Utilization

Compare memory usage across all Indexer nodes.

One node consuming substantially more heap than others may indicate:

• Uneven shard allocation
• Hot indices
• Query imbalance
• Hardware differences

Balanced memory utilization generally indicates that workloads are being distributed correctly.

Resource Bottlenecks

Memory is not the only resource that affects Indexer performance.

Also check for:

• CPU saturation
• High disk latency
• Network congestion
• Thread pool exhaustion

These issues often increase request execution times, causing more concurrent operations to accumulate in memory.

Related Guide: How to Fix a Yellow Cluster Status in Wazuh Indexer

Identify Expensive Queries

Many circuit breaker exceptions originate from inefficient searches rather than insufficient heap.

Slow Logs

Enable or review slow search logs to identify searches requiring unusually long execution times.

Slow queries often involve:

• Large aggregations
• Wide wildcard searches
• Multiple nested filters
• Large time ranges

The same searches usually consume significant heap memory.

Search Profiling

OpenSearch’s Profile API allows administrators to understand exactly where search time and resources are being spent.

Search profiling can reveal:

• Expensive aggregations
• Inefficient filters
• Costly scripts
• Poor query design

Dashboard Queries

Dashboards frequently execute multiple searches simultaneously.

Review dashboards that:

• Load slowly
• Generate many visualizations
• Cover long time periods
• Execute complex aggregations

Simplifying these dashboards often eliminates memory pressure without requiring additional hardware.

Review Index Statistics

The structure of your indices directly affects memory consumption.

Index Size

Very large indices increase search complexity.

Determine:

• Average index size
• Largest indices
• Growth rate over time

Oversized indices may benefit from rollover policies or improved retention management.

Document Count

High document counts increase:

• Search complexity
• Aggregation memory
• Cache requirements

Rapid document growth may indicate excessive log collection or overly aggressive retention settings.

Shard Allocation

Review how shards are distributed across Indexer nodes.

Common problems include:

• Too many tiny shards
• Uneven shard placement
• Oversharding

Each shard consumes heap memory regardless of its size.

OpenSearch documentation emphasizes avoiding excessive shard counts because every shard introduces additional memory overhead.

Monitor System Resources

Finally, examine the underlying operating system.

RAM Usage

Verify:

• Available physical RAM
• Free memory
• Cached memory
• Memory pressure

If the operating system itself lacks available memory, increasing JVM heap may simply shift the bottleneck elsewhere.

CPU Utilization

Sustained CPU usage above 90% often accompanies memory-related issues.

Heavy CPU utilization may result from:

• Garbage collection
• Query execution
• Segment merges
• Bulk indexing

Disk I/O

Slow storage delays indexing and search operations.

Monitor:

• Disk latency
• Read throughput
• Write throughput
• Queue depth

High disk latency causes requests to remain active longer, increasing heap consumption.

Swap Activity

Swap usage is generally a warning sign for OpenSearch clusters.

If JVM pages are swapped to disk:

• Garbage collection becomes slower.
• Query latency increases.
• Circuit breaker exceptions become more common.

OpenSearch best practices strongly recommend avoiding swap whenever possible to maintain predictable JVM performance.

How to Fix circuit_breaking_exception

Once you’ve identified the source of the memory pressure, you can begin applying targeted optimizations.

In many environments, resolving the issue requires several smaller improvements rather than a single configuration change.

Increase JVM Heap Size Safely

If your cluster consistently operates near its heap limits, increasing the JVM heap may provide immediate relief.

Recommended Heap Sizing

OpenSearch generally recommends:

• Allocate approximately 50% of system RAM to JVM heap.
• Leave the remaining memory available for the operating system filesystem cache.
• Avoid heap sizes larger than roughly 32 GB to preserve compressed object pointers and maximize JVM efficiency.

Increasing heap beyond recommended limits often provides diminishing returns.

Heap Allocation Best Practices

When adjusting heap:

• Increase memory gradually.
• Monitor garbage collection afterward.
• Verify overall system memory remains healthy.
• Ensure sufficient RAM remains available for the operating system.

Simply allocating more heap without addressing inefficient workloads may only postpone future circuit breaker exceptions.

Related Guide: How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes

Restart Considerations

Heap size changes require restarting the affected Indexer node.

For production clusters:

• Restart one node at a time.
• Confirm cluster health before proceeding.
• Avoid restarting multiple nodes simultaneously unless performing planned maintenance.

Reduce Search Memory Consumption

Search optimization often provides the largest reduction in heap usage.

Limit Aggregation Sizes

Large aggregation buckets require significant memory.

Reduce:

• Bucket counts
• Cardinality calculations
• Nested aggregations
• Large terms aggregations

Smaller aggregations frequently return the same operational insight while consuming far less heap.

Reduce Returned Documents

Avoid retrieving thousands of documents when only summaries are required.

Instead:

• Lower the size parameter.
• Paginate results.
• Retrieve only necessary fields.

Smaller result sets reduce both heap usage and response times.

Narrow Search Scopes

Restrict searches whenever possible.

Examples include:

• Smaller time ranges
• Specific indices
• Host-specific searches
• Alert-level filtering

Searching fewer documents requires substantially less memory.

Avoid Unnecessary Wildcard Queries

Wildcard searches dramatically increase the number of terms examined.

Prefer:

• Exact matches
• Prefix queries where appropriate
• Structured filters
• Keyword fields

These query types are generally much more memory efficient.

Optimize Dashboard Queries

Dashboards are a common source of repeated high-memory searches.

Simplify Visualizations

Reduce unnecessary visualizations that perform expensive aggregations.

For example:

• Combine similar charts.
• Remove redundant widgets.
• Eliminate unused panels.

Shorten Time Ranges

Viewing the previous 24 hours instead of the previous year dramatically reduces the number of documents processed.

Default dashboard time ranges should reflect operational requirements rather than maximum retention.

Reduce Simultaneous Panels

Each dashboard panel executes one or more searches.

Dashboards with dozens of visualizations may generate substantial concurrent memory usage.

Splitting large dashboards into smaller purpose-built dashboards often improves responsiveness.

Optimize Bulk Indexing Operations

Large ingestion jobs frequently trigger parent circuit breaker exceptions.

Reduce Batch Sizes

Instead of sending extremely large bulk requests:

• Use smaller batches.
• Measure throughput.
• Monitor heap utilization.

Smaller batches usually provide more consistent indexing performance while reducing memory spikes.

Throttle Ingestion

If indexing consistently overwhelms the cluster:

• Reduce ingestion rate.
• Limit concurrent bulk operations.
• Queue incoming data when possible.

Controlled ingestion often produces higher sustained throughput than attempting to ingest everything simultaneously.

Schedule Imports During Low Usage

Large historical imports should ideally run:

• Overnight
• During maintenance windows
• Outside business hours

Separating heavy indexing from peak search activity reduces competition for heap memory.

Delete or Archive Old Indices

Older security data often consumes resources long after it is actively used.

Implement Retention Policies

Establish retention policies that automatically:

• Delete expired indices
• Roll over active indices
• Archive historical data

Well-defined retention policies reduce both storage consumption and heap overhead.

Related Guide: How to Configure Wazuh Log Retention

Free Heap and Storage Resources

Removing obsolete indices reduces:

• Cluster metadata
• Shard count
• Search scope
• Cache requirements

These improvements collectively lower memory consumption across the cluster.

Reduce Shard Count

Oversharding is a common but often overlooked cause of memory pressure.

Consolidate Small Indices

Numerous tiny indices consume considerably more heap than fewer appropriately sized indices.

Combining small indices reduces:

• Cluster metadata
• Background tasks
• Memory overhead

Follow Shard Sizing Recommendations

OpenSearch recommends avoiding both excessively small and excessively large shards.

Maintaining appropriately sized shards helps balance indexing performance, recovery times, and heap utilization.

Optimize Index Mappings

Efficient mappings reduce memory requirements during searches.

Use Keyword Fields Appropriately

Fields intended for filtering, sorting, or aggregations should generally use keyword mappings rather than analyzed text fields.

This reduces field data usage and improves query performance.

Disable Unnecessary Field Data

Field data should only be enabled when absolutely necessary.

Disabling unused field data prevents unnecessary heap allocations during searches.

Remove Unused Fields

Large mappings containing obsolete fields increase indexing complexity and memory usage.

Removing unused fields simplifies indices and improves overall efficiency.

Scale the Wazuh Indexer Cluster

When workloads continue growing, infrastructure expansion may be the most sustainable solution.

Add Additional Nodes

Additional Indexer nodes provide:

• More aggregate heap memory
• Increased indexing capacity
• Improved query distribution
• Greater fault tolerance

Scaling horizontally is often preferable to continually increasing heap on existing nodes.

Balance Workloads

Ensure shards are distributed evenly across all nodes.

Balanced workloads prevent individual nodes from reaching circuit breaker limits while others remain underutilized.

Increase Available Memory

If physical RAM is consistently exhausted, upgrading server memory may be necessary.

Additional RAM allows:

• Larger JVM heap allocations
• More filesystem cache
• Reduced garbage collection pressure
• Improved indexing throughput

Related Guide: How to Build a Wazuh Indexer Cluster

Verifying the Fix

After implementing one or more optimizations, verify that the cluster remains stable under normal workloads.

Successful remediation should improve both memory utilization and overall search performance.

Confirm Circuit Breaker Errors Have Stopped

Begin by reviewing the Indexer logs.

Review Logs

Search for any new occurrences of:

circuit_breaking_exception

or

[parent] Data too large

A sustained absence of these errors during normal operation indicates that the underlying memory issue has likely been resolved.

Monitor Cluster Stability

Observe the cluster over several days, particularly during periods of peak indexing and heavy dashboard usage.

Watch for:

• Stable node uptime
• Healthy cluster status
• No recurring request failures
• Consistent query performance

Long-term stability is a stronger indicator of success than a brief period without errors.

Monitor JVM Heap Usage

Continue monitoring heap metrics after applying changes.

Ensure Healthy Memory Utilization

A healthy cluster should typically maintain sufficient free heap to absorb temporary workload spikes without approaching circuit breaker thresholds.

Rather than operating continuously above 90% utilization, heap usage should fluctuate naturally as indexing and searches occur.

Observe Garbage Collection Behavior

Garbage collection should become:

• Less frequent
• Shorter in duration
• More effective at reclaiming memory

Reduced GC activity generally confirms that heap pressure has decreased.

Test Previously Failing Searches

Repeat the operations that originally produced the exception.

Repeat Problematic Queries

Execute:

• Historical searches
• Large dashboard views
• Aggregation-heavy reports
• Bulk indexing jobs

If these operations now complete successfully, the applied optimizations have likely addressed the original bottleneck.

Validate Successful Execution

Confirm that:

• Searches return complete results.
• Dashboards load normally.
• API requests finish without errors.
• No circuit breaker exceptions appear during execution.

Testing under realistic workloads provides greater confidence than relying solely on monitoring metrics.

Monitor Indexing Performance

Finally, verify that indexing continues to operate efficiently.

Confirm Stable Ingestion Rates

Monitor:

• Incoming event rates
• Indexing throughput
• Queue sizes
• Processing latency

Stable ingestion indicates the cluster has sufficient resources to handle current workloads.

Watch for Delayed Indexing

Ensure new alerts appear promptly in the Wazuh Dashboard without unusual delays.

If indexing latency remains low while searches execute successfully and heap utilization stays within healthy limits, your Wazuh Indexer is well-positioned to handle future growth without recurring circuit_breaking_exception errors.