Free disk space via the Elastic Cloud API console

When a deployment fills up, Kibana usually becomes unreachable before you can open Dev Tools. Elastic Cloud exposes an API Console that talks straight to Elasticsearch and works even while Kibana is unavailable.

Open it from cloud.elastic.co → your deployment → Elasticsearch → API Console. All requests below run there.

1. Confirm the cluster is full

GET /_cat/allocation?v

Look at disk.percent — anything ≥ 90% is why writes (and Kibana’s .kibana_* indices) are blocked.

2. Find the biggest indices

GET /_cat/indices?v&s=store.size:desc&h=index,health,rep,docs.count,store.size,pri.store.size

Sorted largest first, only the columns you need. Sizes are human-readable (1.2gb, 340mb); rep is the replica count, and store.size vs pri.store.size shows how much of the footprint is replicas. Time-series indices (logs-2026.01.*, filebeat-7.17.0-2024.*, etc.) are the usual culprits.

3. Delete what you don’t need

Single index:

DELETE /logs-2026.01.15

Wildcard (be careful — this is irreversible):

DELETE /logs-2026.01.*

Wildcard deletes are refused by default — action.destructive_requires_name defaults to true since Elasticsearch 8.0. Nothing on the request itself lifts that (expand_wildcards only selects which index states a wildcard matches, open/closed/hidden — it is not an override). The only way through is the cluster setting:

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

Set it back to true the moment you’re done. Use persistent, not transient — transient cluster settings are deprecated since 7.16 and can clear unexpectedly when the cluster is unstable, which is exactly the situation you’re in.

4. Lift the read-only flood-stage block

Since Elasticsearch 7.4 the flood-stage block is released automatically once disk drops back below the high watermark — usually within a minute. If indices are still read-only after that (older cluster, or the block was set by hand), clear it explicitly:

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

Re-check GET /_cat/allocation?v — disk.percent should be down and Kibana should come back within a minute or two.

Data streams

If the “indices” you see are prefixed .ds- (e.g. .ds-logs-myapp-default-2026.01.15-000123), they’re backing indices of a data stream — don’t DELETE them directly, the data stream will end up in a broken state. List the streams instead:

GET /_data_stream

Drop a whole stream (irreversible — all backing indices go with it):

DELETE /_data_stream/logs-myapp-default

To trim old backing indices without dropping the stream, attach an ILM policy with a delete phase at e.g. 30 days; existing old indices age out on the next ILM run.

Prevention

Configure Index Lifecycle Management (ILM) so old indices roll over and delete themselves instead of needing a manual cleanup next time.