For an UNASSIGNED shard, unassigned.reason can describe the event that made it unassigned. It does not necessarily describe why allocation is still blocked now. First distinguish a primary from a replica to assess the impact more accurately.
GET _cat/shards?format=json&h=index,shard,prirep,state,unassigned.reason,node
GET _cluster/allocation/explain
{
"index": "example-index",
"shard": 0,
"primary": true
}These are read examples for your own cluster API console; replace index, shard and primary with the actual target. Read can_allocate and the deciders inside node_allocation_decisions together, as described in Elastic’s diagnostic guide. Avoid requesting an arbitrary shard and treating its explanation as evidence for another one.
One historical event can lead to different current actions
For example, a historical NODE_LEFT can coexist with a current disk_threshold decision or a filter decision, requiring different checks. A single node with nowhere to place a replica differs from losing a valid primary copy. For no_valid_shard_copy, investigate valid copies, recoverable nodes and backups rather than describing it merely as reduced redundancy.
Preserve index settings, cluster settings and defaults before changing their interaction. Repeating retry_failed while the blocking condition persists does not remove it. Allocating an empty primary or accepting data loss must not be used merely to restore a dashboard color.
After a correction, compare explanation and allocation for the same shard, then verify index reads, writes and redundancy. These cases illustrate a decision structure; they are not recovery measurements from a running cluster.