Elasticsearch IndexClosedException: Index is closed - Common Causes & Fixes

IndexClosedException: closed is raised when an Elasticsearch read, write, or admin operation targets an index whose state is close. Closed indices retain their data on disk but do not load shards into memory and do not accept search or index requests. The error itself is benign and does not affect other indices or the cluster state.

What This Error Means

Elasticsearch index state is one of open or close. Closing an index drops its in-memory Lucene readers and stops shard activity, freeing JVM heap and file descriptors while keeping the data files on disk. Closed indices are not searchable: a _search request explicitly targeting one (or a wildcard pattern matching it) raises IndexClosedException unless the request passes ignore_unavailable=true.

Frozen indices (a deprecated 7.x feature, replaced by the frozen tier in 8.x) and indices in ILM cold/frozen phases behave similarly under the hood.

Common Causes

1. Manual POST <index>/_close was called. How to confirm: cluster log shows closing indices [...] at the timestamp.
2. ILM policy moved the index to a phase that closes it. How to confirm: GET <index>/_ilm/explain shows the current phase and action.
3. Flood-stage disk watermark applied read_only_allow_delete and a follow-on automation closed the index. How to confirm: GET <index>/_settings for index.blocks.*; check _cat/allocation for nodes above 95% disk.
4. Wildcard search matched a closed index. How to confirm: the error names the specific index in the request that failed; check _cat/indices?v for status: close.
5. Snapshot restore left an index closed. How to confirm: GET _snapshot/<repo>/<snapshot>/_status and check the restore options that were used.

How to Fix IndexClosedException

1. List closed indices in the cluster:

   GET _cat/indices?v&h=index,status,health
   

2. Reopen the affected index:

   POST /<index>/_open
   

   Opening triggers recovery; for large indices this can take minutes. Track with:

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

3. For search calls against wildcards, skip closed indices instead of erroring:

   GET my-logs-*/_search?ignore_unavailable=true
   

   Or set the request option expand_wildcards=open.

4. Check ILM state if the index was managed:

   GET <index>/_ilm/explain
   

   If the policy intentionally closed it (cold phase), restoring queryability means either advancing the policy step or moving the index back to a hot/warm phase manually.

5. For disk-pressure closes, free disk first, then lift blocks:

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

6. Reopen indices opened-but-not-recovered after a restore:

   POST _snapshot/<repo>/<snapshot>/_restore { "indices": "<name>", "include_aliases": false }
   

Resolve IndexClosedException Automatically with Pulse

Pulse is an AI DBA for Elasticsearch and OpenSearch. When IndexClosedException: closed blocks a read or write, Pulse:

• Reads _cat/indices?v&h=index,status,health for all close-state indices, traces the closure to ILM via <index>/_ilm/explain, the master node log's closing indices [...] entries, or disk flood-stage signals from _cat/allocation?v and index.blocks.*
• Identifies which of the five causes applies: a manual POST <index>/_close, an ILM phase that closes the index (cold/frozen), flood-stage watermark at 95% disk plus follow-on automation, a wildcard search matching a closed index, or a snapshot restore that left it closed
• Generates the exact remediation: the POST /<index>/_open call (with the _cat/recovery/<index>?active_only=true watch), the ?ignore_unavailable=true or expand_wildcards=open parameter for application searches, or the PUT /<index>/_settings { "index.blocks.read_only_allow_delete": null } lift after freeing disk
• Applies index reopens and block clears with operator approval; leaves ILM policy phase adjustments and client query updates as one-click PRs

Pulse flags unexpected closed indices continuously, so a misfiring ILM transition or a flood-stage close shows up before customer searches start returning IndexClosedException.

Start a free trial to connect your cluster.

Frequently Asked Questions

Q: Can I search a closed index in Elasticsearch?
A: No. A closed index does not load shards into memory, so search and read operations fail with IndexClosedException. Open the index first or restore it from a snapshot to a different name.

Q: How much memory does a closed index save?
A: A closed index drops all Lucene readers from heap, frees fielddata and segment-level structures, and releases the per-shard file descriptors. Savings scale with shard count and segment count - typically tens to hundreds of MB of heap per closed index on a busy cluster.

Q: What is the difference between closing an index and deleting it?
A: Closing keeps all data files on disk and is reversible with _open. Deleting removes the files irrecoverably. Closed indices count against cluster.max_shards_per_node and disk usage; deleted indices do not.

Q: Why does ILM close indices automatically?
A: ILM cold-phase freeze action and pre-8.x cold-phase configurations could close indices to reduce heap. In 8.x, ILM uses the cold and frozen tiers (searchable snapshots, partially mounted indices) instead, so closing is less commonly used by default.

Q: How long can an index stay closed safely?
A: Indefinitely, on disk. Closed indices do not corrupt over time. Be aware they may not be searchable when needed; for archival, snapshot to a repository instead.

Q: Can I bulk-open many closed indices?
A: Yes. POST <pattern>/_open opens all matching indices. Watch master-node load and the recovery queue - opening hundreds of indices simultaneously can saturate indices.recovery.max_bytes_per_sec.

Q: What's the fastest way to diagnose IndexClosedException in production?
A: Pulse, the AI DBA for Elasticsearch and OpenSearch, ties each IndexClosedException to its source - ILM cold-phase action, manual _close call, flood-stage block, or wildcard expanding to a closed index - and proposes either the _open call or the application-side ignore_unavailable=true parameter. It applies the reopen with approval and watches future ILM transitions so the same pattern does not surprise clients.

Related Reading

• Elasticsearch IndexShardClosedException: the per-shard counterpart.
• Elasticsearch cluster block read-only low disk watermark: related disk-pressure blocks.
• Elasticsearch allocation explain API: for allocation failures after reopening.
• Elasticsearch cluster health check: inspecting overall cluster state.
• Elasticsearch monitoring: tracking ILM and index state changes.