---
title: Index Queue Size
description: Describes what AutoOps detects and surfaces with the Index Queue Size insight: The write thread pool queue on a data node is backed up with pending indexing work.
url: https://docs-v3-preview.elastic.dev/elastic/autoops-insights/tree/main/elasticsearch/index_queue_size
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
---

# Index Queue Size
The write thread pool queue on a data node is backed up with pending indexing work. When the queue stays high, the node cannot keep pace with ingest and might reject writes or slow co-located searches.
<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     | Node                  |
| Domains   | performance, indexing |


## 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 |
|---------------------------------|---------|---------|
| Write queue threshold           | Integer | 1       |
| Successive samplings to trigger | Integer | 1       |

<tip>
  Raising these thresholds reduces noise but delays detection. Lowering them triggers the insight sooner but can increase alerts during minor blips.
</tip>


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

### The index queue is high on node: `es-data-01`


#### What was detected

The affected node: `es-data-01` and `es-data-02` High search activity indices:`logs-prod-000045` High indexing activity indices:`logs-prod-000045`

#### Recommendations

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

<dropdown title="Rollover indices">
  **Condition**: Shown when high-indexing activity is detected and if index has less primary shards than available data nodes.If logs-prod-000045 are time-based, roll them over and set 2 primary shards on the new write index so you can avoid a heavy segment merge on the current indices.
</dropdown>

<dropdown title="Rollover indices by shard size">
  **Condition**: Shown when high-indexing activity is detected and if primary shard size > 30GB.If logs-prod-000045 are time-based, roll them over when average shard size reaches your target.
</dropdown>

<dropdown title="Review index templates and mappings">
  **Condition**: Shown when high-indexing activity is detected and for indexes with highest indexing latency.Review templates and mappings for logs-prod-000045; they strongly affect indexing performance. Fix oversized mappings, unnecessary fields, and inefficient index settings.
</dropdown>

<dropdown title="Review indexing slow logs">
  **Condition**: Shown when high indexing activity is detected on the node.Enable indexing slow logs with the action below on logs-prod-000045, then review the logs to find slow index operations. On Elasticsearch 8.14+, set `index.indexing.slowlog.include.user` to `true` to record which user triggered a slow operation.
  ```json

  {
    "index.indexing.slowlog.threshold.index.warn": "10s",
    "index.indexing.slowlog.threshold.index.info": "5s",
    "index.indexing.slowlog.threshold.index.debug": "2s",
    "index.indexing.slowlog.threshold.index.trace": "500ms",
    "index.indexing.slowlog.source": "1000"
  }
  ```

  <note>
    Requires the `manage` index 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 high-indexing activity is detected and if index has more primary shards as available data nodes.Add a data node to increase capacity and reduce pressure on the existing nodes.
</dropdown>

<dropdown title="Review indexing slow logs">
  **Condition**: Always shown for this insight.Check indexing slow logs on `es-data-01` to find expensive indexing operations and address the root cause.
</dropdown>


#### Background and impact

Impact: This indicates that a data node (temporarily) does not have resources to process all indexing requests. This could result in rejected indexing operations and slower search operations.
Queues are used to hold the pending requests that can’t be carried out immediately. If there are many index requests coming to the node that can’t be processed at the same time, the requests are sent to the queue.
A high index queue might form due to a temporary surge of requests from client applications, but it is more often a symptom of index performance issues in the node.
If the queue is high you should check slow logs to investigate the root causes.