How to Delete an Index in Elasticsearch

To delete an index in Elasticsearch, send DELETE /<index_name>. The call removes the index, its mappings, its documents, and all underlying shards from disk in one step. There is no undo: once the cluster state reflects the deletion, the only way back is restoring from a snapshot. That is why production clusters since Elasticsearch 8.0 ship with action.destructive_requires_name set to true by default, requiring explicit index names rather than wildcards.

This guide covers the DELETE API and everything you should think about before pressing enter on it: safety settings, data stream caveats, snapshots, role-based access, soft-delete patterns, and how ILM can automate the whole thing for you.

The Basic Delete Index Request

DELETE /my-index

The response is {"acknowledged": true} once the cluster state has been updated. Shard files are removed asynchronously on each data node, so the disk reclamation lags the API response by a few seconds on large indices.

You can delete several indices in one request:

DELETE /index-a,index-b,index-c

That is the only safe way to delete multiple indices on a default 8.x or 9.x cluster, because wildcards are blocked.

Wildcards, _all, and action.destructive_requires_name

Since Elasticsearch 8.0, the action.destructive_requires_name cluster setting defaults to true, which blocks DELETE /*, DELETE /_all, and any wildcard pattern that could match more than one index. If you try, you will get:

illegal_argument_exception: Wildcard expressions or all indices are not allowed

To enable wildcard deletes (almost never a good idea in production), change the setting:

PUT /_cluster/settings
{
  "persistent": {
    "action.destructive_requires_name": false
  }
}

The dedicated `action.destructive_requires_name` setting guide covers the trade-offs in detail. The short version: leave it alone. The handful of operations that need bulk deletion can either list indices explicitly or run through ILM.

The expand_wildcards parameter controls which kinds of indices a pattern can match: open, closed, hidden, all, or none. Even with destructive operations allowed, you can pass expand_wildcards=open to avoid accidentally taking out closed indices.

Data Streams: You Cannot Delete the Write Index

This is the gotcha that surprises most teams the first time they move to data streams. You cannot delete the current write index of a data stream directly. The official docs are explicit:

You cannot delete the current write index of a data stream. To delete the index, you must roll over the data stream so a new write index is created. You can then use the delete index API to delete the previous write index.

The flow looks like this:

POST /my-data-stream/_rollover
DELETE /.ds-my-data-stream-2026.05.13-000001

If you want to delete the entire data stream (all backing indices in one step), use the data stream API instead:

DELETE /_data_stream/my-data-stream

That removes the data stream and every backing index. For routine retention, use the ILM delete phase or data stream lifecycle policies, not manual deletes.

Before You Delete Anything

A few habits that have saved real incidents:

1. Stop the writes. If anything is still indexing into the index you are about to delete, the index will reappear as soon as you turn around (default action.auto_create_index is permissive). Either pause the writer or set `action.auto_create_index` to false while you clean up.
2. Check what is reading from it. Search the application config, dashboards, and saved searches for the index name and any alias that points at it. The fast way is to query _alias and _cat/indices to confirm the index does not have unexpected aliases pointing at it.
3. Take a snapshot. A snapshot is your only safety net. If you are using the built-in snapshot repository, a single call is all it takes:

PUT /_snapshot/my-repo/pre-delete-2026-05-13?wait_for_completion=true
{
  "indices": "my-index",
  "include_global_state": false
}

4. Check disk and master health. Deleting many indices at once produces a burst of cluster-state updates and shard cleanups. On a cluster already showing master pressure or low disk watermarks, space out the work.

Use ILM for Routine Deletion

Manual DELETE calls are appropriate for one-off cleanup. For recurring retention (logs older than 30 days, events older than a quarter), the Index Lifecycle Management delete action is the safer pattern:

PUT /_ilm/policy/logs-30d
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_age": "1d", "max_primary_shard_size": "30gb" }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": { "delete": {} }
      }
    }
  }
}

Attach the policy at index creation via the index template, and Elasticsearch handles rollover and deletion automatically. No human ever runs DELETE /logs-* again, and the failure modes (action.destructive_requires_name, accidental wildcards, fat fingers) disappear.

Soft-Delete With an Alias Swap

If you want the option to recover quickly without a full snapshot restore, point the application at an alias, swap the alias to a placeholder index, then delete the underlying index after a cool-off period.

POST /_aliases
{
  "actions": [
    { "remove": { "index": "products-v1", "alias": "products" } },
    { "add":    { "index": "products-empty", "alias": "products" } }
  ]
}

# wait a day, confirm nothing is searching products-v1 anymore
DELETE /products-v1

This pattern is especially useful for reindex-style migrations: keep the old index around, behind no alias, for a few days before reclaiming the disk. See the aliases guide for the full pattern.

Closed and Hidden Indices

Closed indices can be deleted with the same DELETE API. There is no need to open them first. Hidden indices (names starting with .) are deletable too, but most are managed by Elasticsearch itself (.security, .kibana, .monitoring-*). Deleting one of those will cause feature breakage and the cluster will often re-create them shortly after. Leave system indices alone unless you are following a documented Elastic procedure.

RBAC: Who Can Delete an Index

Under the built-in security model, deleting an index requires the delete_index index privilege. The default roles map as follows:

• superuser: can delete anything (use sparingly).
• manage on an index pattern: includes delete_index for that pattern.
• viewer, editor, data_steward: typically lack delete privileges.

In production, scope delete_index narrowly. Give applications write on their own indices, give SREs manage only on the patterns they actually operate, and require a separate privileged role for one-off cleanups.

Deleting From a Client Library

Python (elasticsearch-py)

es.indices.delete(index="my-index", ignore_unavailable=True)

JavaScript (@elastic/elasticsearch)

await client.indices.delete({ index: 'my-index', ignore_unavailable: true })

Java REST client

client.indices().delete(d -> d.index("my-index"));

The ignore_unavailable: true option is useful in idempotent cleanup scripts; without it, deleting a non-existent index returns a 404.

Recovering a Deleted Index

There is no built-in undo. Your options are:

1. Restore from a snapshot. This is the only first-class recovery path. POST /_snapshot/my-repo/<snapshot>/_restore { "indices": "my-index" }.
2. Reindex from a replica copy. If you happen to have a cross-cluster replication follower or a recent reindex destination still around, copy from there.
3. Recover from dangling indices. If the shard files were not removed from every data node (rare, but happens after split-brain or rolling restarts), Elasticsearch may surface the index as dangling and you can import it. This is best-effort, not a recovery strategy.

If none of those apply, the data is gone. Plan accordingly.

Common Errors When Deleting an Index

• index_not_found_exception: the index name is wrong, or already deleted. Use _cat/indices to confirm.
• illegal_argument_exception: Wildcard expressions or all indices are not allowed: action.destructive_requires_name is enforcing the safety check. List the indices explicitly.
• security_exception: action [indices:admin/delete] is unauthorized: the user or API key lacks the delete_index privilege.
• cluster_block_exception with read_only or read_only_allow_delete: the cluster is in a read-only state, usually because of low disk watermarks. Resolve the block before retrying.
• cannot delete the write index [...] of data stream: roll the data stream over first.

How Pulse Helps With Index Lifecycle

Most of the painful index-deletion incidents we see at Pulse trace back to the same root causes: no ILM policy attached, no snapshot before a bulk cleanup, or an index that turned out to still be in production traffic despite looking abandoned. Pulse continuously inspects Elasticsearch and OpenSearch clusters, flagging indices without an ILM policy, indices growing past their declared retention, snapshots that have not run on schedule, and aliases that point at unexpected indices. When you do need to delete something, you can do it knowing the alias graph, snapshot status, and ILM coverage at a glance. Connect your cluster to Pulse and let it surface the index-lifecycle risks before they turn into incidents.

Best Practices Checklist

• Keep action.destructive_requires_name at its default true (since Elasticsearch 8.0).
• Snapshot before any non-routine deletion.
• Stop writers before deleting; check `action.auto_create_index` is not configured to recreate the index.
• For data streams, roll over before deleting the previous write index.
• Use ILM for recurring retention; reserve manual DELETE for one-off cleanup.
• Point applications at an alias so deletion never breaks application code.
• Scope delete_index privilege narrowly. Most service accounts should not have it.
• Avoid deleting hidden system indices (.security, .kibana).
• Watch for cluster blocks: if disk is hot, deletion can fail or fan out latency.

Frequently Asked Questions

Q: Can I undelete an Elasticsearch index?

No. Once the cluster state is updated, the only recovery path is restoring from a snapshot. If the data matters, snapshot first.

Q: How do I delete multiple indices at once?

List them explicitly: DELETE /index-a,index-b. Wildcards (DELETE /logs-*) are blocked by default since Elasticsearch 8.0 and you should not turn that protection off. For recurring retention, use the ILM delete phase.

Q: Will deleting a large index hurt cluster performance?

Briefly. The cluster state update is fast, but reclaiming the shard files on disk and rebalancing the cluster can produce IO and CPU pressure. On a cluster already showing pressure, delete during quieter hours and watch the cluster health endpoint.

Q: How do I stop someone from accidentally deleting all indices?

Three layers: leave action.destructive_requires_name at true, scope the delete_index privilege narrowly, and route any bulk cleanup through ILM rather than direct API calls. For an extra belt-and-braces option, set `cluster.indices.close.enable` to disable index closing and use index.blocks.write on production indices.

Q: Can I delete a closed index without opening it first?

Yes. The DELETE API works on open, closed, and hidden indices.

Q: How do I find out what is using an index before deleting it?

Check aliases with GET /<index>/_alias. Watch live traffic with the slow query log or Pulse Query Analytics to see whether anything is actively reading from the index. Search application configs and dashboards for the index name and any aliases pointing to it.

Q: Does deleting an index also remove its index template?

No. Index templates and the indices they create are independent. If you want to stop a template from creating new matching indices, delete the template separately with DELETE /_index_template/<name>.