Elasticsearch IndexShardClosedException: Index shard is closed - Common Causes & Fixes

IndexShardClosedException: CurrentState[CLOSED] operation on shard [<index>][<shard>] is not allowed is raised by Elasticsearch when an internal operation targets a shard whose IndexShard instance has transitioned to the CLOSED state. The shard is no longer accepting reads or writes. The cluster continues to operate; only the affected shard is unavailable until it is reopened or reallocated.

What This Error Means

Each shard copy in Elasticsearch is represented by an IndexShard object on the node hosting it. That object transitions between states (CREATED, RECOVERING, POST_RECOVERY, STARTED, RELOCATED, CLOSED) over its lifecycle. A CLOSED shard usually means the parent index was closed via the close-index API, the node is draining the shard before it relocates, or recovery failed and the shard was torn down. The exception is most often seen during shard movement, node shutdowns, or interaction with closed indices.

This is different from IndexClosedException, which is raised when an operation targets a closed index as a whole.

Common Causes

1. The parent index was closed via POST <index>/_close. How to confirm: GET _cat/indices/<index>?v shows status: close.
2. Shard is relocating; the source copy was closed mid-flight. How to confirm: GET _cat/shards/<index>?v shows RELOCATING or transient INITIALIZING entries.
3. Recovery failed and the shard was closed before retry. How to confirm: GET _cluster/allocation/explain for the failed shard reports the recovery failure cause.
4. Node shutdown in progress; shards are being closed for clean handoff. How to confirm: GET _nodes/<name>/_all/shutdown shows the shutdown status (8.x feature).
5. Disk flood-stage watermark forced index closure (writes are blocked but shards may also be closed under pressure). How to confirm: GET _cat/allocation?v for any node above 95% disk.

How to Fix IndexShardClosedException

1. Check whether the index is closed:

   GET _cat/indices/<index>?v
   

2. Reopen the index if it was intentionally closed:

   POST /<index>/_open
   

3. For in-flight relocations, wait and re-check. Relocation completes in seconds to minutes depending on shard size:

   GET _cat/recovery/<index>?v&active_only=true
   

4. For failed recovery, ask the cluster why:

   GET /_cluster/allocation/explain
   {"index":"<index>","shard":0,"primary":false}
   

   Apply the named fix (disk space, allocation filter, node availability).

5. If a node is in shutdown, complete or cancel the shutdown action; shards will reopen on their target nodes.

6. For disk flood-stage, free disk and lift the index read-only block:

   PUT /<index>/_settings
   {"index.blocks.read_only_allow_delete": null}
   

7. Retry failed allocations after the underlying issue is fixed:

   POST /_cluster/reroute?retry_failed=true
   

Resolve IndexShardClosedException Automatically with Pulse

Pulse is an AI DBA for Elasticsearch and OpenSearch. When IndexShardClosedException: CurrentState[CLOSED] fires for an internal operation, Pulse:

• Correlates the shard state from _cat/shards/<index>?v, active recoveries from _cat/recovery?active_only=true, the master node's elasticsearch.log shard transition history, _cat/allocation?v disk usage, and any in-progress _nodes/<name>/_all/shutdown actions (8.x)
• Identifies which of the five causes applies: explicit POST <index>/_close, in-flight relocation, recovery failure that tore the shard down, node shutdown drain, or disk flood-stage at 95% that triggered the read-only block
• Generates the exact remediation: the POST /<index>/_open call for intentional closures, the _cluster/allocation/explain query plus the named fix for recovery failures, the PUT /<index>/_settings { "index.blocks.read_only_allow_delete": null } lift, or the POST /_cluster/reroute?retry_failed=true retry
• Applies index reopen, allocation retry, and block-removal automatically with operator approval; leaves disk capacity changes and node shutdown coordination as one-click PRs

Pulse alerts on closed shards and stuck recoveries continuously so a relocation that hangs mid-flight surfaces before the read side gets routed to a CLOSED replica copy.

Start a free trial to connect your cluster.

Frequently Asked Questions

Q: What is the difference between IndexShardClosedException and IndexClosedException?
A: IndexClosedException is raised when an operation targets a fully-closed index (POST /<index>/_close). IndexShardClosedException is raised when an internal operation targets a single shard copy that has been closed on a specific node - the index as a whole may still be open.

Q: Can I read data from a closed shard?
A: No. A CLOSED IndexShard does not accept reads or writes. If another copy of the shard (primary or replica) is STARTED elsewhere, the cluster routes requests there transparently.

Q: Will IndexShardClosedException cause data loss?
A: Not by itself. The shard's Lucene files remain on disk. Data loss only occurs if every copy of a shard is lost (e.g., disk failure on the only node holding it). Always run with at least one replica.

Q: Does Elasticsearch automatically reopen a closed shard?
A: Allocation will retry up to index.allocation.max_retries times (default 5) after a recovery failure. After that, you must manually retry via _cluster/reroute?retry_failed=true. Intentionally closed indices stay closed until _open is called.

Q: How do I prevent shards from being closed during a node restart?
A: Use the node shutdown API in 8.x to drain the node gracefully (POST _nodes/<name>/_all/shutdown { "type": "restart" }). For older versions, set cluster.routing.allocation.enable: primaries temporarily and disable shard relocations during the restart.

Q: Is it safe to use the close-index API on a production cluster?
A: Yes when done deliberately. Closed indices free heap and reduce file descriptors. The data is preserved and can be reopened later. Avoid closing indices that backing services still query - the application will see IndexClosedException until reopen.

Q: What's the fastest way to diagnose IndexShardClosedException in production?
A: Pulse, the AI DBA for Elasticsearch and OpenSearch, ties the CLOSED shard state to the concurrent recovery, relocation, shutdown, or disk-watermark event that triggered it, parsing _cat/shards, _cat/recovery, _cluster/allocation/explain, and the master log together. It applies the right next step - _open, ?retry_failed=true reroute, or block lift - after operator approval.

Related Reading

• Elasticsearch IndexClosedException: the index-level counterpart.
• Elasticsearch NoShardAvailableActionException: when no shard copy is available.
• Elasticsearch allocation explain API: root-cause tool for allocation failures.
• Elasticsearch cluster block read-only low disk watermark: related disk-driven blocks.
• Elasticsearch monitoring: proactive shard state monitoring.