The cluster.indices.close.enable setting is the cluster-wide on/off switch for the close-index API. Its default is true, meaning users with the right permissions can close indices freely. Setting it to false makes every call to POST /<index>/_close return an error, regardless of the caller's privileges. This is useful when you want to enforce an organizational policy that indices stay searchable, or to prevent an Index Lifecycle Management (ILM) close action from running during a sensitive window.
Definition
cluster.indices.close.enable is a dynamic cluster-level boolean. Closing an index releases its in-memory data structures and stops it from serving reads and writes, but its data stays on disk. The setting governs only the close operation; it does not affect _open, index creation, or deletion. Index deletion is gated separately by action.destructive_requires_name.
Default and Allowed Values
| Property | Value |
|---|---|
| Default | true |
| Type | Boolean, dynamic cluster setting |
When true |
Close API works normally for users with manage privilege |
When false |
All close attempts fail with an error; existing closed indices stay closed |
| Affects | Manual closes, ILM close actions, programmatic SDK calls |
| Does not affect | Open, create, delete, freeze (deprecated in 7.14) |
How to Change It
# Block all close operations cluster-wide
PUT /_cluster/settings
{
"persistent": {
"cluster.indices.close.enable": false
}
}
# Re-allow close operations
PUT /_cluster/settings
{
"persistent": {
"cluster.indices.close.enable": null
}
}
Inspect:
GET /_cluster/settings?include_defaults=true&filter_path=*.cluster.indices.close.enable
When to Disable Closing
Three legitimate reasons to set this to false:
- Search availability policy. If your application code or downstream tools assume every index in a pattern is queryable, a closed index produces confusing 4xx responses. Disabling close ensures the assumption holds.
- Disabling ILM close as a step. If an ILM policy uses the
closeaction and you want to pause it without rewriting the policy, this setting blocks it cluster-wide. The ILM history will show the close failing rather than silently transitioning. - Maintenance window before backup or migration. When taking a logical backup or running a reindex migration, you do not want indices closing mid-flight.
For most clusters the default true is correct. Disabling close removes a useful operational tool (closing old indices to reduce heap pressure without deleting them).
Operational Impact
When cluster.indices.close.enable: false:
POST /<index>/_closereturns400 Bad Requestwithclosing indices is disabled - set [cluster.indices.close.enable: true] to enable it.- ILM transitions that include a
closeaction stall on that step. - Existing closed indices stay closed; the setting does not auto-reopen them.
- Open operations are unaffected;
POST /<closed-index>/_openstill works to re-bring closed indices online.
Closed indices occupy disk but no JVM heap. They cannot be searched, written to, or have their mappings updated. The close action exists precisely for archival or seasonal data where you want to keep the bytes around without paying the heap cost.
Common Mistakes
- Disabling close to "prevent accidental data loss". Close is not destructive; data on disk is preserved. Delete is the destructive operation, which is gated by
action.destructive_requires_name, not this setting. - Confusing close with freeze. Freeze (deprecated in 7.14, removed in 8.0) was a different operation that kept indices searchable but with minimal heap. The frozen tier in 7.12+ uses searchable snapshots instead, and is not affected by this setting.
- Forgetting ILM dependencies. If your ILM policy uses
close, disabling this setting will cause stuck transitions and yellow ILM health in monitoring. - Setting
falsetransiently. Usepersistentso a full cluster restart does not silently re-enable close.
Frequently Asked Questions
Q: What is the default for cluster.indices.close.enable?
A: The default is true, which allows authorised users to close indices via the close-index API. Setting it to false blocks all close operations cluster-wide.
Q: Does cluster.indices.close.enable affect index deletion?
A: No. This setting only gates the close API. Deletion is controlled separately by action.destructive_requires_name, which when true requires an explicit index name (rather than a wildcard) for delete operations.
Q: What happens to already-closed indices if I set this to false?
A: They stay closed. The setting does not auto-reopen anything. You can still reopen them with POST /<index>/_open because the _open operation is not gated by this setting.
Q: How does cluster.indices.close.enable interact with ILM?
A: If an ILM policy includes the close action, setting cluster.indices.close.enable: false will cause that action to fail and the index's ILM transition to stall on that step. Either remove the close action from the policy or re-enable the setting.
Q: Can I change cluster.indices.close.enable without restarting?
A: Yes. It is a dynamic cluster setting. Use PUT /_cluster/settings and the change applies immediately. No node restart is required.
Q: Why would I close an index instead of deleting it?
A: Closing releases JVM heap (used by mapping, segment metadata, fielddata, etc.) while keeping the data on disk. It is the right choice for old data you might need to reopen later for ad-hoc queries but do not want to keep loaded.
