---
title: Status Red
description: Describes what AutoOps detects and surfaces with the Status Red insight: Cluster health is red because at least one primary shard is unassigned or unavailable.
url: https://docs-v3-preview.elastic.dev/elastic/autoops-insights/tree/main/elasticsearch/status_red
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
---

# Status Red
Cluster health is red because at least one primary shard is unassigned or unavailable. Affected indices cannot accept writes and might return incomplete search results.
<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  | Critical                          |
| Scope     | Cluster                           |
| Domains   | cluster-health, high-availability |


## 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              |
|-----------------------------------------------|-----------------|----------------------|
| Minimum duration of the red status in seconds | Integer         | 0                    |
| Index name patterns excluded from red status  | List of strings | partial-*,restored-* |


## 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 cluster status is red


#### What was detected

The current number of unassigned primary shards is: 12. The maximum number of unassigned shards is: 12. The number of initializing shards is: 12. Current allocation blocker: Disk low watermark is blocking primary shard allocation on the hot, warm tier.
truetrue See 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="Wait for shard initialization to complete">
  **Condition**: Shown when only initializing shards.There initializing. Wait for initialization to finish; cluster status should update when all shards are ready.
</dropdown>

<dropdown title="Wait for shard recovery to complete">
  **Condition**: Shown when data node is disconnected and might rejoin.Shard recovery is in progress after data nodes restarted or were removed: `es-data-01`. Wait until recovery finishes before making other cluster changes.
</dropdown>

<dropdown title="Explore shard allocation in the cluster">
  **Condition**: Shown when no initializing shards.Use cluster allocation explain to see why shards are unassigned for index logs-prod-000045, shard 0. Run the action below.
  ```json
  ```

  <note>
    Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action is read-only.
  </note>
</dropdown>

<dropdown title="Check total shards per node limit">
  **Condition**: Shown when no initializing shards AND disk watermark or data-tier capacity is NOT the likely allocation blocker.`index.routing.allocation.total_shards_per_node` on logs-prod-000045 might block replica assignment. Fetch index settings with the action below and adjust or remove the limit if it causes unassigned shards.
  ```json
  ```

  <note>
    Requires the `manage` index privilege. Requires Elasticsearch 8.0.0 or later. This action is read-only.
  </note>
</dropdown>

<dropdown title="Retry failed shard allocations">
  **Condition**: Shown when any shard failed to be allocated.If shards failed to allocate and nothing is recovering, retry allocation with a cluster reroute. Use the action below (`retry_failed=true`).
  ```json
  ```

  <note>
    Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>

<dropdown title="Restore red index from snapshot">
  **Condition**: Shown when allocation is NOT blocked by a disk watermark or data-tier capacity constraint (that is, primary data is likely unrecoverable).If you have a snapshot of the red index, delete the index and restore it from that snapshot.
</dropdown>

<dropdown title="Allocate empty primary (data loss)">
  **Condition**: Shown when any index has lost a primary shard AND allocation is NOT blocked by a disk watermark or data-tier capacity constraint (data is intact).Only if you accept data loss for index logs-prod-000045 shard 0, allocate an empty primary with `accept_data_loss` to return the cluster toward green. Use the action below.
  ```json

  { "commands" : [ { "allocate_empty_primary" : { "index" : "logs-prod-000045", "shard":0, "node" : "es-data-02", "primary": "true" "accept_data_loss": true } } ] }
  ```

  <note>
    Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>

<dropdown title="Delete unrecoverable red index">
  **Condition**: Shown when the red index is not recoverable AND allocation is NOT blocked by a disk watermark or data-tier capacity constraint.If departed nodes cannot rejoin and affected indices cannot be recovered, delete them with the action below. This step is irreversible and should be a last resort to restore cluster health.
  ```json
  ```

  <note>
    Requires the `manage cluster` privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>

<dropdown title="Temporary disk watermark increase">
  **Condition**: Shown when a disk watermark breach on a non-frozen data tier (hot, warm, cold, or content) is the likely current allocation blocker; prefer gating via the existing DISK_WATERMARK_LOW indication.Temporarily raise the disk watermark so you can free space before the cluster restricts shard allocation. After you reclaim disk, return the watermark to its previous value. Use the action below to update `cluster.routing.allocation.disk.watermark.high`.
  ```json

  {
    "transient": {
      "cluster.routing.allocation.disk.watermark.high": "90%"
    }
  }
  ```

  <note>
    Requires the `manage cluster` 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 index replication exceeds available data nodes OR a non-frozen data-tier capacity shortfall is the likely current allocation blocker (capacity-blocked OR replication-blocked).Add a data node to increase capacity and reduce pressure on the existing nodes.
</dropdown>


#### Background and impact

Impact: Some data is not available for search and there is a high probability of data loss. Red status means one or more primary shards are unavailable. While this persists, affected indices cannot accept writes and search results are incomplete. The root cause is not always data loss: allocation rules that block placement while data is still intact, such as disk watermarks or capacity limits on a data tier, are a common cause alongside node outages and failed recoveries. This might also be transient following a node restart or during snapshot restore of indices on cold or frozen tiers. Confirm why shards stay unassigned before accepting data loss or deleting an index. You can reduce alert noise by configuring an exclusion pattern for lower-risk index families or a minimum red duration for transient events. If neither suppression applies, investigate urgently.