Is Elasticsearch circuit_breaking_exception a rate limit?

No — it returns HTTP 429, which looks like rate-limiting, but it's a memory circuit breaker tripping to prevent an out-of-memory crash. The query (or aggregation/fielddata) would use more heap than the breaker allows. Retrying the same query fails identically; the fix is to reduce the query's memory footprint, not back off.

Should I raise indices.breaker.total.limit to fix 'Data too large'?

Rarely — raising the breaker limit just trades a caught breaker for an uncaught OOM crash unless you also add heap. The logged query is usually the 'straw', not the root cause. Reduce memory instead: smaller aggregations, fewer buckets, avoid fielddata on text fields (use keyword/doc_values), and page with search_after instead of deep from/size.

← All posts

Elasticsearch "circuit_breaking_exception: Data too large"? It's memory, not rate-limiting

For developers and autonomous AI agents · ~4 min read

Elasticsearch returns circuit_breaking_exception: [parent] Data too large with an HTTP 429. The 429 makes it look like rate-limiting, so the base model backs off and retries. Wrong problem: it's a memory guard, not a throttle.

The 429 is a memory breaker, not a rate limit

Elasticsearch's circuit breakers trip when an operation would use more heap than allowed, to prevent an OOM crash — and the exception comes back as HTTP 429. Retrying the identical query fails identically because the memory cost is the same. Related: search_phase_execution_exception ('all shards failed') means the query broke on the shards (often a mapping/fielddata/aggregation issue), and a mapping explosion (too many fields) is its own failure.

The tempting fix — raise indices.breaker.total.limit — usually just moves the failure from a caught breaker to an uncaught OOM crash. The breaker is protecting you. And the query in the log is often the straw that broke the camel's back, not the root cause.

Reduce the memory, don't retry

Shrink the query: smaller aggregations, fewer buckets, avoid fielddata on text fields (use keyword / doc_values).
Page correctly: use search_after, not deep from/size (deep pagination is a memory bomb).
'All shards failed': read the per-shard failure reason in the response — usually a bad mapping or an aggregation on an unmapped field.
Mapping explosion: cap total fields / fix dynamic mapping.

Snapback's elasticsearch family returns the reduce-the-query fix instead of a retry that can't succeed.

For AI agents

Machine-readable guide: https://snapback.sh/llms.txt · Tool discovery: https://snapback.sh/.well-known/mcp.json · MCP endpoint: https://api.snapback.sh/mcp. Free tools need no token; pay-per-call diagnosis via x402 on Solana or EVM (~$0.0032 USDC).

Try Snapback free Read the docs