---
title: Write hotspotting
description: Describes what AutoOps detects and surfaces with the Write hotspotting insight: Write work is backing up on a subset of write-eligible nodes while peer nodes in the same eligible set still have spare capacity.
url: https://www.elastic.co/docs/reference/autoops-insights/elasticsearch/write_hotspotting
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
---
# Write hotspotting
Write work is backing up on a subset of write-eligible nodes while peer nodes in the same eligible set still have spare capacity. This usually points to uneven shard placement or competing search and indexing work on the busy nodes, which raises ingest latency and leaves available write capacity unused.
For a complete list of insights, refer to [AutoOps insights](https://www.elastic.co/docs/reference/autoops-insights/elasticsearch).
## Insight details
| Field | Value |
|-----------|-----------------------------------------------------------------------|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | performance, search, indexing, resource-utilization, 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-edge.elastic.dev/docs/deploy-manage/monitor/autoops/ec-autoops-event-settings) for details.
The default customization settings are:
| Setting | Type | Default |
|------------------------------------------------------|---------|---------|
| Write queue threshold to count a node as overloaded | Integer | `50` |
| Consecutive samples meeting the imbalance conditions | Integer | `3` |
Raising these thresholds reduces noise but delays detection. Lowering them triggers the insight sooner but can increase alerts during minor blips.
## 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.
### Write work is concentrated on es-data-01
#### What was detected
The write thread pool queue is elevated on `es-data-01` and `es-data-02` while other write-eligible nodes in the same set have no writes waiting.
- Indices with high indexing activity: `logs-prod-000045`
- Indices with high search activity on the same nodes: `logs-prod-000045`
Related open insights on these nodes:
- Disk watermark flood stage
- Deployment not highly available
[Inspect open insights](https://cloud.elastic.co/deployments/d3pl0yment01?eventTypes=DISK_WATERMARK_FLOOD_STAGE,CLUSTER_NOT_HA)
#### Recommendations
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
**Condition**: Shown when hotspot-related events are open.These open events on the overloaded nodes might explain competing work or how far this write hotspot has gone. Open the list and resolve each event, then recheck write queue depth.[Inspect open events](`es-data-01` and `es-data-02`)
**Condition**: Always shown for this insight.Review search and indexing load on es-data-01 for the indices listed in this insight. Tune or relocate hot indices if they dominate node activity.
**Condition**: Shown when search is competing on the overloaded nodes and cluster version is 9.4 or above.Review query logs on es-data-01 to find expensive searches that fill the queue. Query logs (Elasticsearch 9.4+) give structured per-query timing with less overhead than search slow logs. See [Query logs](https://docs-edge.elastic.dev/docs/deploy-manage/monitor/logging-configuration/query-logs).
**Condition**: Shown when search is competing on the overloaded nodes and cluster version is below 9.4.Enable search slow logs with the action below, then review the slow log to find expensive queries. See [Slow logs](https://docs-edge.elastic.dev/docs/deploy-manage/monitor/logging-configuration/slow-logs) for configuration details.
```json
{
"index.search.slowlog.threshold.query.warn": "10s",
"index.search.slowlog.threshold.query.info": "5s",
"index.search.slowlog.threshold.query.debug": "2s",
"index.search.slowlog.threshold.query.trace": "500ms",
"index.search.slowlog.threshold.fetch.warn": "1s",
"index.search.slowlog.threshold.fetch.info": "800ms",
"index.search.slowlog.threshold.fetch.debug": "500ms",
"index.search.slowlog.threshold.fetch.trace": "200ms"
}
```
Requires the `manage` index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
**Condition**: Shown when one or more related long-running tasks on the overloaded nodes are cancellable.Cancel long-running tasks (es-data-01:4521, es-data-02:7788) that are affecting cluster stability. Use the action below.
```json
```
Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
**Condition**: Shown when high search activity is present on the overloaded nodes and the affected index has no replica.Set `number_of_replicas` to 1 on logs-prod-000045 (currently 2) using the action below.
```json
{
"index": {
"number_of_replicas": 1
}
}
```
Requires the `manage` index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
**Condition**: Shown when the same hot index appears in both indexing and search activity, or write-heavy shards are not well spread across write-eligible nodes.Node es-data-01 holds 1000 shards while es-data-02 holds 12. Move shard 0 of index logs-prod-000045 from es-data-01 to es-data-02 using the action below.
```json
{
"commands": [
{
"move": {
"index": "logs-prod-000045",
"shard": 0,
"from_node": "es-data-01",
"to_node": "es-data-02"
}
}
]
}
```
Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
**Condition**: Shown when search is quiet on the overloaded nodes, high indexing activity is detected, and the hot index has fewer primary shards than the available write-eligible data nodes.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.
**Condition**: Shown when search is quiet on the overloaded nodes, high indexing activity is detected, and primary shard size is above 30GB.If logs-prod-000045 are time-based, roll them over when average shard size reaches your target.
**Condition**: Shown when search is quiet on the overloaded nodes and high indexing activity is concentrated on the indices with the 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.
**Condition**: Shown when search is quiet on the overloaded nodes and 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"
}
```
Requires the `manage` index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
**Condition**: Shown when search is quiet on the overloaded nodes, high indexing activity is detected, and the hot index already has at least as many primary shards as the available write-eligible data nodes.Add a data node to increase capacity and reduce pressure on the existing nodes.
#### Background and impact
A write hotspot happens when indexing pressure concentrates on a few write-eligible nodes instead of being spread across the tier. This often reflects uneven shard placement, hot shards, or competing search, merge, and indexing work on the same nodes.
If the imbalance persists, ingest latency rises on the busy nodes, write queues can grow into rejections, and searches on those nodes can also slow down. Other write-eligible nodes stay underused, so the problem is distribution of work rather than uniform cluster-wide saturation.
## Guide
[Hotspotting](https://docs-edge.elastic.dev/docs/troubleshoot/elasticsearch/hotspotting)