Elasticsearch Open and Close Index: API, Use Cases, and Caveats

To close an Elasticsearch index, send POST /<index>/_close. To open it again, send POST /<index>/_open. A closed index is blocked from reads and writes and stops consuming the in-memory structures (segment metadata, query caches) that an open index keeps in RAM. It still occupies disk space. Closing is most often used as a prerequisite for updating static settings, or for dormant indices you want to keep on disk without paying the heap cost. Both APIs work on Elasticsearch 7.x, 8.x, and 9.x with the same syntax.

This guide covers when to close, what is blocked while closed, the safety setting that controls whether closing is allowed at all, and the modern alternatives (frozen tier, cold tier) that have largely replaced closed-index workflows.

The Basic API

# Close
POST /my-index/_close

# Open
POST /my-index/_open

Both calls return acknowledged: true and a shards_acknowledged flag once the cluster state is updated. Opening an index recovers its shards from disk, which can take seconds to minutes depending on shard size and node count.

Wildcards and lists are supported (subject to action.destructive_requires_name, since closing is treated as a destructive action):

POST /logs-2025-*/_close
POST /index-a,index-b/_open

The wait_for_active_shards parameter applies to _open and controls how many shard copies must be active before the call returns. Default is 0 (return as soon as the request is accepted); set to all to wait until every replica has come up.

When to Close an Index

There are three legitimate reasons to close an index:

1. Updating a static setting. Settings like index.number_of_shards, index.codec, and analyzer definitions can only be changed on a closed index. Close, update with the update index settings API, reopen.
2. Keeping dormant data on disk without paying heap. Closed indices consume nearly zero heap. If you have historical indices that get queried once a quarter, closing them frees JVM memory while keeping the data instantly available after a reopen.
3. Pre-snapshot prep on legacy workflows. This is mostly obsolete. Modern snapshots work on open indices and are the recommended path.

Most teams should not be closing indices in 2026. The frozen tier or cold tier covers case 2 better (queries work without an explicit reopen step). Case 1 is the one that still matters: certain settings genuinely require a closed index.

What Is Blocked on a Closed Index

A closed index cannot serve reads or writes. Specifically:

• Search, msearch, get, mget: fail with index_closed_exception.
• Index, update, bulk: fail with index_closed_exception.
• _cat/indices shows the index with status close.
• Aggregations and analytical APIs that target the index fail.
• ILM transitions on the index pause (the index is excluded from active phase actions).

What still works:

• Snapshot and restore.
• Cluster-level operations (delete index, update non-active settings).
• Reopening.

The cluster.indices.close.enable Safety Setting

The cluster setting cluster.indices.close.enable controls whether closing is allowed at all. It defaults to true. Some managed Elasticsearch providers ship it as false to prevent users from accidentally locking themselves out of data.

# Check
GET /_cluster/settings?include_defaults=true&filter_path=*.cluster.indices.close.enable

# Disable
PUT /_cluster/settings
{
  "persistent": {
    "cluster.indices.close.enable": false
  }
}

When this is false, every _close call returns an error. Useful as a guardrail in environments where you do not want operators reaching for close as a tactical fix.

See the dedicated cluster.indices.close.enable setting guide for the full trade-off discussion.

Modern Alternatives: Frozen and Cold Tiers

In current Elasticsearch versions, the better answer for "keep data around without paying heap" is usually the frozen tier (with searchable snapshots) or the cold tier. These give you:

• Queryable data without an explicit reopen step.
• Far lower memory footprint than even closed indices (the frozen tier uses partial caching).
• Native ILM integration for moving indices across tiers based on age.

The migration pattern:

1. Define ILM phases for hot, warm, cold, frozen, delete.
2. Attach the policy to your indices via an index template.
3. Let Elasticsearch move indices across tiers as they age, instead of opening and closing them manually.

For the conceptual breakdown, see the hot-warm-cold scaling guide.

Data Streams

Data streams cannot be closed directly. To close a backing index of a data stream, target the backing index by name:

POST /.ds-logs-app-2026.05.13-000001/_close

In practice, you almost never want to close a data stream backing index. Use ILM to move it to a cheaper tier instead.

Common Pitfalls

• Closing an index that an alias points at. Reads through the alias will see the closed index as unavailable. Queries that span multiple indices via the alias return partial results or fail, depending on ignore_unavailable.
• Closing the write index of a data stream. Indexing fails until the data stream is rolled over to a new write index.
• Forgetting that opening takes time. On a large index, _open initiates shard recovery. The cluster will be yellow until replicas catch up. Plan opens during low-traffic windows for large historical indices.
• Reaching for close when frozen would be better. Closed indices are not queryable; frozen indices are. If your reason for closing is "we still need to query this occasionally," frozen is the right tool.

How Pulse Helps With Open/Close Decisions

Closed indices are easy to forget about: they do not show up in dashboards, they do not affect query latency, and they quietly hold disk for months until someone notices. Pulse tracks closed indices on Elasticsearch and OpenSearch clusters and surfaces ones that have been closed longer than makes sense, indices closed without an ILM policy that would have handled them, and clusters where closing is being used as a workaround for what should be a tier transition. Connect your cluster to Pulse and let it surface the index-state drift before it becomes a forgotten cost.

Frequently Asked Questions

Q: Does a closed index take up disk space?

Yes. Closed indices keep their data on disk; only the in-memory cost is freed. If you want to reclaim disk, you need to delete or snapshot-and-delete.

Q: Can I search a closed index?

No. Searches return index_closed_exception. You must reopen first.

Q: How long does opening a large index take?

Shard recovery has to read segment metadata from disk and rebuild in-memory structures. For a 50 GB index on healthy hardware, expect tens of seconds. For larger indices, minutes. The cluster will be yellow until replicas come up.

Q: Why would _close return an error?

The two common reasons: cluster.indices.close.enable is set to false (the cluster operator disabled closing), or the index is part of a data stream and you are targeting the stream rather than a backing index.

Q: Can I update settings on a closed index?

Yes, that is the main reason to close. Static settings like analyzers and index.codec can only be modified on a closed index. See update index settings for the workflow.

Q: Is closing the same as archiving?

Not really. Closing is a runtime state; archiving usually means snapshot + delete. For long-term retention, snapshot to S3 (or another snapshot repository) and delete the index. For data you still need to occasionally query, use the frozen tier with searchable snapshots, which is essentially an archive that you can search.