Total and max shard conflict
Elastic Cloud Hosted lets you manage and configure one or more deployments of the versioned Elastic Stack, hosted on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Elastic Cloud on Kubernetes extends Kubernetes orchestration capabilities to allow you to deploy and manage components of the Elastic Stack. Availability This functionality is generally available and ready for production usage. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes. Elastic Cloud Enterprise is a self-managed orchestration platform for deploying and managing the Elastic Stack at scale. Availability This functionality is generally available and ready for production usage. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes. Self-managed deployments are Elastic Stack deployments managed without the assistance of an orchestrator. Availability This functionality is generally available and ready for production usage. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
ECH
Generally available
ECK
Generally available
ECE
Generally available
Self-managed
Generally available
A finite cluster.routing.allocation.total_shards_per_node hard cap on your data nodes conflicts with cluster.max_shards_per_node or leaves too little headroom to place shards after a node loss or during rebalancing. Elasticsearch defaults this hard cap to unlimited (-1) so allocation can move shards freely.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Cluster |
| Domains | configuration, shard-allocation, stability |
The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.
cluster.routing.allocation.total_shards_per_node is 800. cluster.max_shards_per_node is 1000. Data nodes: 3. One-node-loss headroom needs at least 1500 shards per node at full budget.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Raise or clear the total shards per node hard cap
Condition: Always shown for this insight.
cluster.routing.allocation.total_shards_per_node is set to 800, which is too low relative to your cluster shard budget or rebalance headroom. Raise it to 1500 (at least 1500 if you keep a finite cap), or set it to -1 (unlimited, the Elasticsearch default) if you do not need a hard per-node cap. Review whether you still need a finite cap before clearing it.
PUT _cluster/settings?pretty{ "persistent": { "cluster.routing.allocation.total_shards_per_node": "1500" } }
Requires the manage cluster privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
Add data node
Condition: Shown when the hard cap leaves too little room to rebalance after a data node loss.
Add a data node to increase capacity and reduce pressure on the existing nodes.
Lower the maximum shards per node to the recommended value
Condition: Shown when cluster.max_shards_per_node is above the recommended default of 1000 and lowering it is an acceptable alternative to raising the hard cap.
Set cluster.max_shards_per_node to 1000 to bring the cluster back within the recommended shard budget. Review index and shard design first so future growth stays within the limit, and prefer right-sizing indices and adding nodes over raising this setting.
PUT _cluster/settings?pretty{ "persistent": { "cluster.max_shards_per_node": "1000" } }
Requires the manage cluster privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
cluster.max_shards_per_node sets a cluster-wide shard budget (roughly the setting times the number of data nodes). cluster.routing.allocation.total_shards_per_node is a hard per-node placement cap. When that hard cap is finite and tighter than the budget share, or too close to the load you need after losing a data node, Elasticsearch can leave shards unassigned during recovery or rebalancing.
Elasticsearch defaults the hard cap to unlimited (-1) so nodes can absorb shards when topology changes. Prefer raising or clearing a conflicting hard cap, adding data nodes, or reducing shard count. Lower cluster.max_shards_per_node only when the cluster budget itself should shrink.