---
title: Total and max shard conflict
description: Describes what AutoOps detects and surfaces with the Total and max shard conflict insight: 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.
url: https://docs-v3-preview.elastic.dev/elastic/autoops-insights/tree/main/elasticsearch/total_and_max_shard_conflict
products:
  - Elastic Cloud Enterprise
  - Elastic Cloud Hosted
  - Elastic Cloud on Kubernetes
  - Elasticsearch
applies_to:
  - Elastic Cloud Hosted: Generally available
  - Elastic Cloud on Kubernetes: Generally available
  - Elastic Cloud Enterprise: Generally available
  - Self-managed Elastic deployments: Generally available
---

# Total and max shard conflict
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.
<note>
  For a complete list of insights, refer to [AutoOps insights](https://docs-v3-preview.elastic.dev/elastic/autoops-insights/tree/main/elasticsearch).
</note>


## Insight details


| Field     | Value                                      |
|-----------|--------------------------------------------|
| Component | Elasticsearch                              |
| Severity  | Medium                                     |
| Scope     | Cluster                                    |
| Domains   | configuration, shard-allocation, stability |


## Example: What you might see in AutoOps

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.

### Total and max shard settings conflict


#### What was detected

`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.

#### Recommendations

<note>
  AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
</note>

<dropdown title="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.
  ```json

  {
    "persistent": {
      "cluster.routing.allocation.total_shards_per_node": "1500"
    }
  }
  ```

  <note>
    Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>

<dropdown title="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.
</dropdown>

<dropdown title="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.
  ```json

  {
    "persistent": {
      "cluster.max_shards_per_node": "1000"
    }
  }
  ```

  <note>
    Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>


#### Background and impact

`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.

## Guide

[Troubleshoot shard capacity health issues](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/troubleshoot/elasticsearch/troubleshooting-shards-capacity-issues)