---
title: Indexing throttle time
description: Describes what AutoOps detects and surfaces with the Indexing throttle time insight: One or more nodes are throttling indexing because they cannot keep up with the current ingest rate.
url: https://www.elastic.co/docs/reference/autoops-insights/elasticsearch/indexing_throttle_time
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
---

# Indexing throttle time
One or more nodes are throttling indexing because they cannot keep up with the current ingest rate. Throttling slows writes on purpose to protect the node.
<note>
  For a complete list of insights, refer to [AutoOps insights](https://www.elastic.co/docs/reference/autoops-insights/elasticsearch).
</note>


## Insight details


| Field     | Value                 |
|-----------|-----------------------|
| Component | Elasticsearch         |
| Severity  | High                  |
| Scope     | Node                  |
| Domains   | performance, indexing |


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

### Indexing is being throttled on es-data-01


#### What was detected

Indexing throttle time is elevated on es-data-01.
Index with high indexing activity: `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 fewer primary shards than the available hot data nodes, or all data nodes when no hot role exists.If logs-prod-000045 are time-based, roll them over and set 1 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**: Always shown for this insight.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 than the available hot data nodes, or all data nodes when no hot role exists.Add a data node to increase capacity and reduce pressure on the existing nodes.
</dropdown>


#### Background and impact

Indexing throttle means the data node is limiting the rate of write work because it cannot keep up with demand. That protects the node, but it also delays how quickly new documents become searchable.
If throttling continues, indexing requests might start getting rejected. Upstream producers that retry aggressively can add more load. In the worst case, data lags or is lost when clients do not retry failed writes.