Cluster Health, Shard Sizing and Replicas

Reading health and sizing shards

GET _cluster/health reports green (all primary and replica shards allocated), yellow (all primaries allocated but some replicas are not, common on a single-node cluster because a replica is never placed on the same node as its primary) or red (at least one primary is unassigned, so some data is unavailable). _cat/indices, _cat/shards and _cluster/allocation/explain show which shards are unassigned and why (disk watermarks, missing nodes, allocation rules). Shard sizing: too many small shards waste heap and cluster-state overhead, while huge shards recover slowly. Elastic's guidance commonly suggests shards of roughly 10 to 50 GB and avoiding thousands of tiny shards; check the docs for your version. Plan replicas for availability (at least one) and add more only if you need read throughput.

Keeping the cluster healthy

Healthy clusters have sensible shard counts, indices managed through aliases and lifecycle policies, and a practised reindex path.

Everyday health checks

Kibana Dev Tools console syntax; send the same requests with curl or a client library.

GET /_cluster/health

GET /_cat/nodes?v&h=name,node.role,heap.percent,disk.used_percent,cpu

GET /_cat/indices?v&s=store.size:desc

GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason

# why is a shard not allocated?
GET /_cluster/allocation/explain
{
  "index": "orders",
  "shard": 0,
  "primary": false
}

Watch disk watermarks

When a node passes the high disk watermark, Elasticsearch moves shards away; at the flood-stage watermark it blocks writes to affected indices. Alert on disk usage well before that.

Quick check: A single-node cluster with replicas set to 1 is usually what colour?

• Blue
• Green
• Red
• Yellow, because replicas cannot be placed on the node holding the primary