Elasticsearch CircuitBreakingException: Data too large, circuit breaking - Common Causes & Fixes

CircuitBreakingException: [<breaker>] Data too large, data for [<source>] would be [X/...gb], which is larger than the limit of [Y/...gb] is logged when an operation in Elasticsearch would push JVM heap usage past one of the configured circuit breaker limits. The request is rejected before the allocation happens, which protects the node from OutOfMemoryError. Other queries continue to run. The exception names which breaker tripped - parent (default 95% of heap), request (60%), fielddata (40%), or accounting (100%) - and the immediate fix depends on which it is.

What This Error Means

Elasticsearch uses four indices.breaker.* circuit breakers to estimate the memory cost of an operation before allocating it. The parent breaker tracks total heap reservations across all breakers; the others track specific use cases:

The parent breaker's use_real_memory: true mode (default since 7.0) checks actual JVM heap usage rather than estimated, so it can trip even when child breaker estimates look fine.

Common Causes

1. Heap pressure from sustained traffic, large aggregations, or oversize shards. How to confirm: GET _nodes/stats/jvm - look at mem.heap_used_percent.
2. Aggregation cardinality higher than expected. How to confirm: identify the slow query in the slow log and measure its memory with the _search/_profile API.
3. Fielddata loaded on text fields. How to confirm: GET _cat/fielddata?v and look for nonzero entries.
4. Many open Lucene segments (high accounting breaker usage). How to confirm: GET _cat/segments?v and count per-node; consider force-merging read-only indices.
5. JVM heap undersized for the working set. How to confirm: GET _nodes/stats/jvm shows heap_used_percent consistently above 75% even at idle.

How to Fix CircuitBreakingException

1. Identify which breaker tripped. The exception text includes [<breaker_name>]. Treat parent, request, fielddata, and accounting differently.

2. Check live breaker stats:

   GET /_nodes/stats/breaker
   

   Compare each estimated_size_in_bytes to limit_size_in_bytes.

3. For request breaker trips: reduce aggregation cost. Use composite aggregations for pagination instead of large terms agg, cap size on terms aggregations, and avoid cardinality on high-cardinality keyword fields without precision_threshold.

4. For fielddata breaker trips: see the fielddata breaker page. Move aggregations to .keyword subfields backed by doc values.

5. For parent breaker trips: reduce overall heap pressure. Force-merge read-only indices to drop accounting overhead:

   POST /<index>/_forcemerge?max_num_segments=1
   

   Drop the fielddata cache as a short-term release:

   POST /_cache/clear?fielddata=true&query=true&request=true
   

6. Right-size heap. Set heap to 50% of system RAM and no more than ~26 GB (to keep compressed object pointers) per the Elastic heap sizing guidance. Edit config/jvm.options.d/heap.options:

   -Xms16g
   -Xmx16g
   

7. Raise specific breakers only as a last resort. Raising the parent breaker above 95% defeats its purpose; raising fielddata or request requires confidence the heap can hold it.

Resolve CircuitBreakingException Automatically with Pulse

Pulse is an AI DBA for Elasticsearch and OpenSearch. When CircuitBreakingException: Data too large fires, Pulse:

• Reads _nodes/stats/breaker for all four breakers (parent, request, fielddata, accounting) plus in-flight requests, plots estimated_size_in_bytes against limit_size_in_bytes, correlates with _nodes/stats/jvm heap_used_percent, the slow log, and _cat/segments per-node counts
• Identifies which breaker tripped (the [<breaker>] in the exception text) and the dominant heap consumer: request structures from an oversized aggregation, fielddata on a text field, accounting from too many open Lucene segments, or genuine heap undersizing with use_real_memory: true
• Generates the right remediation: the _forcemerge?max_num_segments=1 call on read-only indices, the composite aggregation rewrite with size and precision_threshold caps, the _cache/clear?fielddata=true&query=true&request=true release, the jvm.options.d/heap.options heap resize (50% of RAM up to ~26 GB), or a targeted indices.breaker.*.limit adjustment
• Applies dynamic _cluster/settings changes and cache clears automatically with operator approval; leaves heap-options edits, force-merges, and aggregation rewrites as one-click PRs

Pulse alerts on rising breaker-trip rates and heap_used_percent sustained above 75% so steady-state pressure surfaces before the parent breaker fires under a burst.

Start a free trial to connect your cluster.

Frequently Asked Questions

Q: What is the default circuit breaker limit in Elasticsearch?
A: Defaults vary by breaker: parent 95% (with use_real_memory: true), request 60%, fielddata 40%, accounting 100%, and in-flight requests 100%. All are percentages of the JVM heap.

Q: What does the parent circuit breaker do?
A: The parent breaker (indices.breaker.total.limit, default 95%) tracks total heap reservations across all child breakers and, with use_real_memory: true, also checks actual JVM heap usage. It is the last line of defense before OutOfMemoryError.

Q: How do I find out which query caused the CircuitBreakingException?
A: Enable the search slow log (index.search.slowlog.threshold.query.warn) to capture expensive queries, then match by timestamp to the CircuitBreakingException line in <cluster>.log. The exception itself names the source (request ID or fielddata field name).

Q: Can I disable circuit breakers in Elasticsearch?
A: Setting any breaker limit to -1 disables that specific check, but doing so removes the protection against JVM OutOfMemoryError. Tune workload and heap instead of disabling breakers.

Q: Does a CircuitBreakingException corrupt my index or cause data loss?
A: No. The breaker fires before the allocation, so the rejected request is the only thing affected. The cluster stays running and other queries complete normally. Watch for partial success in _bulk responses.

Q: Why does the parent breaker trip when child breakers report low usage?
A: With use_real_memory: true (default in 7.0+), the parent breaker checks actual JVM heap, not just child reservations. Garbage on heap from unaccounted allocations - including Lucene segment readers, Painless script caches, and incoming network buffers - can push real usage past 95% even when child estimates look fine.

Q: What's the fastest way to diagnose CircuitBreakingException in production?
A: Pulse, the AI DBA for Elasticsearch and OpenSearch, identifies which of the four breakers tripped, names the dominant heap consumer (segments, fielddata, or request structures), and ties the trip to the responsible query, index, or shard. It proposes the right action - force-merge, mapping fix, heap resize, or breaker tuning - and applies dynamic cluster settings automatically when approved.

Related Reading

• Elasticsearch field data circuit breaker tripped: the fielddata-specific case.
• Elasticsearch circuit breaker exceptions fix: cross-breaker remediation walkthrough.
• What is the Elasticsearch field data cache: underlying mechanism.
• Elasticsearch heap size setting: JVM sizing.
• Elasticsearch monitoring: catching breaker trips proactively.