---
title: Oversized shards
description: Describes what AutoOps detects and surfaces with the Oversized shards insight: One or more shards exceed the recommended size range (roughly 50 GB, or a very high document count).
url: https://docs-v3-preview.elastic.dev/elastic/autoops-insights/tree/main/elasticsearch/oversized_shards
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
---

# Oversized shards
One or more shards exceed the recommended size range (roughly 50 GB, or a very high document count). Oversized shards slow recovery, relocation, and search, and in extreme cases can become hard to move or write.
<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     | Index                                           |
| Domains   | performance, index-management, shard-allocation |


## Customization settings

You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to [AutoOps event settings](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/deploy-manage/monitor/autoops/ec-autoops-event-settings) for details.
The default customization settings are:

| Setting                               | Type            | Default  |
|---------------------------------------|-----------------|----------|
| Maximum optimal shard size in GB      | Integer         | `0.0004` |
| Exclude indices based on this pattern | List of strings |          |


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

### There are large shards in the cluster


#### What was detected

Total number of indices with large shards: 12
The index that contains the largest shard is: logs-prod-000045, and the shard size is: 42 GB.
See a sample list: `logs-prod-000045`, `logs-prod-000046`.

#### Recommendations

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

<dropdown title="ILM policy for large shards">
  **Condition**: Always shown for this insight.If logs-prod-000045 is time-based, set or tune its ILM policy so rollover targets roughly 20–30 GB shards.
</dropdown>

<dropdown title="Reindex into smaller indices">
  **Condition**: Shown for non-system indexes.Reindex into smaller indices to reduce shard sizes and improve search performance.
</dropdown>

<dropdown title="Split index into more shards">
  **Condition**: Shown when primary shard count is less than data node count and shard size warrants split.Use the Split API to split logs-prod-000045 (current size 42 GB) into 2 primary shards with the action below. Run during low cluster load and confirm you have enough disk space. See the [Split index API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-split) for prerequisites.
  ```json

  {
    "settings": {
      "index.number_of_shards": 2
    }
  }
  ```

  <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

Index data is partitioned into shards when the index is created. Shard size grows with the data you write into that index.
Shards that grow well beyond about 50 GB, or that hold hundreds of millions of documents, take longer to recover and relocate. Searches that hit those shards can also run more slowly. In extreme cases a shard can approach hard limits (for example around 2 billion documents) and become difficult to write to or move.
Keeping shards in a moderate size range helps the cluster recover faster and keeps search and indexing more predictable as data volume grows.

## Guide

[Size your shards](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/deploy-manage/production-guidance/optimize-performance/size-shards)