Long Running Re-Index Task
A reindex operation has exceeded the configured duration limit. Reindex reads source data via scroll contexts and writes to a destination index, which can take hours on large indices.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | performance, indexing, stability, tasks |
You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to AutoOps event settings for details.
The default customization settings are:
| Setting | Type | Default |
|---|---|---|
| Long running re-index task threshold in minutes | Integer | 60 |
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.
Summary: There are 3 tasks that ran more than the 12 minutes threshold. The longest task running start time was 2026-03-15T14:22:00 UTC time. The longest task running time is 420 ms. ACTIVE TASKS: NodeName: logs-prod-000045- TaskId: es-data-01:4521
TaskSerialNumber: 12
TaskType: logs-prod-000045
Description: bulk index to logs-prod-000045
StartTimeInMillis: 1710502920000
RunningTimeInMinutes: 48
Cancellable: true
Action: indices:data/write/bulk
Headers: {} HISTORY TASKS: NodeName:logs-prod-000045- TaskId: es-data-01:4521
TaskSerialNumber: 12
TaskType: logs-prod-000045
Description: bulk index to logs-prod-000045
StartTimeInMillis: 1710502920000
RunningTimeInMinutes: 48
Cancellable: true
Action: indices:data/write/bulk
Headers: {}
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Improve long reindex tasks
Condition: Shown when always included (reindex tasks are not cancellable.
Use slicing to parallelize reindexing (not supported for remote clusters), temporarily raise or turn off the refresh interval during the run, and review index mappings and analysis for optimization opportunities.
Impact: Long running re-index tasks might affect the cluster performance. It might be perfectly ok to have reindex operations running for a long time. For instance, you have a big index that you need to reindex into one or many indexes with more primary shards to better spread their indexing and search load over more nodes. However, it might be worth understanding how the reindex operation works under the hood, and how it can affect your cluster. Reindex uses the Scroll API to figure out the documents that need to be reindexed. The Scroll API opens a search context that will be kept in memory until the reindex task has terminated, which means that the longer the reindex operation lasts, the longer the memory will be occupied by the search context. Running several reindex operations in parallel worsens the situation even more. Even if the search context is kept alive for 5 minutes by default, it doesn't mean that the entire reindex operation will stop within that time. It can last much longer, as each new batch of reindex will refresh that keep alive timeout for 5 more minutes. For these reasons, there are a few best practices to keep in mind:
- If you don't need to reindex the entire index, specify a sufficiently restrictive search query along with your reindex request, so as to reindex as few documents as necessary
- Do not run too many reindex requests in parallel
- Try to run reindex requests during off-peak hours
- Leverage slicing to better benefit from parallelism
- If you need to reindex your index into an index with more primary shards, it might be better to consider using the Split API
- If you need to reindex your index into an index with less primary shards, it might be better to consider using the Shrink API