http.max_content_length limits the size of any single HTTP request body Elasticsearch will accept. When exceeded, the node responds with HTTP 413 (or in older versions, closes the connection). The setting bounds memory usage from a single request - a 100 MB bulk request takes ~100 MB to read, parse, and buffer before processing. Raising it makes large bulks possible; raising it carelessly is one of the more common contributors to coordinating-node OOMs.
- Default:
100mb - Scope: Per-node, static - set in
elasticsearch.yml, requires restart - Possible values: Any size value (e.g.
200mb,1gb)
How http.max_content_length Works
The HTTP layer parses the Content-Length header (or trailing-chunked total) and compares it against the limit before reading the body. If the declared size is over the limit, the request is rejected without consuming the body bytes. If the client lies about the length and streams more, the parser stops reading after the limit and the request fails.
The setting is per-node, applied at the receiving (coordinating) node. The body must be buffered in the JVM heap before processing - the cost is proportional to body size, not document count. A 500 MB bulk request occupies ~500 MB of heap on the coordinator until parsing completes.
Configuring http.max_content_length
In elasticsearch.yml:
http.max_content_length: 200mb
Restart the node. The setting is static and cannot be changed via the cluster settings API.
When working with large documents or large bulk requests, raise this setting alongside JVM heap. The rough rule: each concurrent in-flight bulk consumes its body size in heap; the coordinating node should have headroom for the typical bulk concurrency.
When to Adjust the Default
| Scenario | Action |
|---|---|
| Default 100mb sufficient for current clients | Leave at default |
| Large reindex jobs hitting 413 errors | Reduce bulk client batch size first; raise the limit only if batches are inherently large |
| Bulk-indexing large documents (e.g. embedded binary content) | Raise to 200-500 MB; ensure heap can absorb the concurrent load |
| Frequent 413 errors from a specific client | Investigate the client - it's likely batching inefficiently |
Raising the limit beyond ~500 MB is rarely a good idea. Bulks that large cause GC pressure on the coordinator regardless of how the data is structured.
Common Pitfalls
- Raising
http.max_content_lengthwithout considering heap size. A node with 4 GB heap and a 1 GB content-length cap can OOM from two concurrent large bulks. - Treating 413 errors as a sizing problem when the real issue is client batching. Most clients should batch in the 5-15 MB range, not 100+ MB.
- Forgetting the setting is static. Changes take effect on next restart, not immediately.
- Setting it differently on different coordinating nodes. Clients see inconsistent behavior depending on which node receives the request.
Related Limits to Check
| Setting | Default | Relationship |
|---|---|---|
http.max_initial_line_length |
4kb |
Limits the request line (URL + headers up to first newline) |
http.max_header_size |
16kb |
Limits total HTTP header size |
indices.breaker.request.limit |
60% of heap | Per-request circuit breaker - also limits aggregation memory |
indices.breaker.total.limit |
95% of heap | Parent breaker - sum of all in-flight memory accounting |
Raising http.max_content_length without raising circuit breaker limits often just moves the failure to circuit-breaker rejection instead of HTTP 413.
Monitoring Large Requests
Track:
- 413 responses (Elasticsearch's audit log or proxy access logs)
indices.breaker.requesttripped count- Coordinating-node heap usage during peak indexing
- Bulk indexing latency p95/p99 - a creeping increase often precedes a 413 wave
Prevent http.max_content_length Misconfiguration with Pulse
Pulse is an AI DBA for Elasticsearch and OpenSearch that tracks http.max_content_length (default 100mb) across every node along with the bulk request size distribution per client, flagging:
- Drift between nodes: a coordinator with
http.max_content_length: 200mbwhile peers stay at 100mb produces inconsistent client behaviour depending on which node receives the request - Settings that are unsafe for your workload (e.g. limit raised to 1 GB on a node with 4 GB heap, where two concurrent oversized bulks will OOM the coordinator; raised without also reviewing
indices.breaker.request.limit) - The downstream operational impact: HTTP 413 rate, circuit-breaker trips, coordinating-node heap during peak indexing, p95 bulk latency
When a client starts producing 500 MB bulks instead of the 5-15 MB sweet spot, Pulse names the client and the originating service - before the cluster starts rejecting traffic or paging the coordinator.
Frequently Asked Questions
Q: What is the default value of http.max_content_length?
A: The default is 100mb. Any HTTP request body larger than 100 MB is rejected by Elasticsearch with HTTP 413 (or connection close in older versions). The limit applies per request, not per second.
Q: How do I fix HTTP 413 "Content too large" errors?
A: Either reduce the client-side bulk batch size (the recommended fix - most bulks should be 5-15 MB) or raise http.max_content_length in elasticsearch.yml. Restart the node for the new value to take effect.
Q: What is a good bulk request size for Elasticsearch?
A: 5-15 MB per bulk request is the typical sweet spot. Smaller bulks underutilize throughput; larger bulks consume coordinator heap and can trigger circuit breakers. The right answer depends on document size, mapping, and hardware - measure throughput as you adjust.
Q: Can I change http.max_content_length without restarting Elasticsearch?
A: No. It's a static node setting that takes effect at startup. Apply changes during a rolling restart.
Q: Does http.max_content_length apply to search requests too?
A: Yes. Any HTTP request body - search, bulk, update-by-query, ingest - is bounded by the setting. In practice, search bodies are tiny so the limit only affects ingest workloads.
Q: What happens when http.max_content_length is exceeded?
A: The node returns HTTP 413 (Request Entity Too Large) and refuses to read the body. The client should reduce the request size and retry. Large bulks that fail consume nothing on the cluster - they're rejected before processing.
Q: What's the best tool to prevent HTTP 413 errors and oversized bulk requests in Elasticsearch?
A: Pulse is built for this. It is an AI DBA for Elasticsearch and OpenSearch that tracks http.max_content_length per node along with bulk size distribution per client, flags pathological batching patterns, and correlates coordinator heap pressure with the originating service - so the fix targets the right side of the wire.
Related Reading
- Elasticsearch Threadpool Write Queue Rejected Execution: Write rejections
- Elasticsearch Circuit Breaker Exceptions Fix: Circuit-breaker trips
- Elasticsearch Bulk Indexing: Bulk API basics
- Elasticsearch JVM Heap Pressure High: Heap pressure
- Elasticsearch thread_pool.write.size Setting: Write concurrency
