Red/yellow cluster triage flow (which index, which shard, why)

Command

GET _cluster/health?filter_path=status,unassigned_shards,initializing_shards,delayed_unassigned_shards,number_of_pending_tasks
GET _health_report?verbose=false
GET _cat/indices?v&health=red&h=health,index,pri,rep,docs.count,store.size
GET _cat/indices?v&health=yellow&h=health,index,pri,rep
GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,unassigned.for,node&s=state
# Without a body, the call explains the first unassigned shard:
GET _cluster/allocation/explain

What it does

Gives an ordered triage flow from cluster status down to the problem indices, then to unassigned shards and the reason they are not allocated (unassigned.reason, allocation explain); _health_report summarizes which indicator (disk, shard availability, master) is unhealthy.

When to use it

As the first response when the cluster turns red or yellow.

Caution

Red: at least one primary shard is unassigned; writes to that index and searches hitting that shard fail. Yellow: all primaries are present but replicas are missing; data is reachable but there is no redundancy. On a single-node cluster, indices with replicas > 0 stay yellow permanently (same_shard decision). If a node left recently, delayed_unassigned_shards are held on purpose until index.unassigned.node_left.delayed_timeout (default 1m) expires.