How To Solve Issues Related to Log – Scheduling reroute for delayed shards in delayed shards

Prevent Your Next ELK Incident

Try our free Check Up to test if your ES issues are caused from misconfigured settings

Fix Issue

Updated: Jan-20

In-Page Navigation (click to jump) :

Opster Offer’s World-Class Elasticsearch Expertise In One Powerful Product
Try Our Free ES Check-Up   Prevent Incident

Troubleshooting background

To troubleshoot Elasticsearch log “Scheduling reroute for delayed shards in delayed shards” it’s important to understand common problems related to Elasticsearch concepts: allocation, cluster, routing, shards. See detailed explanations below complete with common problems, examples and useful tips.

Cluster in Elasticsearch

What is it

In Elasticsearch a cluster is a collection of one or more nodes (servers / VMs). A cluster can consist of an unlimited number of nodes. The cluster provides interface for indexing and storing data and search capability across all of the data which is stored in the data nodes

Each cluster has a single master node that is elected by the master eligible nodes. In cases where the master is not available the other connected master eligible nodes elect a new master. Clusters are identified by a unique name, which defaults to “Elasticsearch”.

Routing in Elasticsearch

What it is

In Elasticsearch, routing refers to document routing. When you index a document, Elasticsearch will determine which shard will be used to index the document to. 

The shard is selected based on the following formula:

shard = hash(_routing) % number_of_primary_shards

Where the default value of _routing is _id.
It is important to know which shard the document is routed to, because Elasticsearch will need to determine where to find that document later on for document retrieval requests. 


In twitter index with 2 primary shards, the document with _id equal to “440” gets routed to the shard number:   

shard = hash( 440 ) % 2
PUT twitter/_doc/440

  • In order to improve search performance speed you can create custom routing. For example, you can enable custom routing that will ensure only a single shard is queried (the shard that contains your data).
  • To create custom routing in Elasticsearch, you will need to configure and define  that not all routing will be completed by default settings. ( v <= 5.0)
PUT my_index/customer/_mapping
  •  This will ensure that every document in the “customer” type must specify a custom routing.  For elasticsearch 6 or above you will need to update the same mapping as:
PUT my_index/_mapping

To help troubleshoot related issues we have gathered selected Q&A from the community and issues from Github , please review the following for further information :

1 Github Issue Number 18293  

2All Shards Failed After One Node Sh  

Github Issue Number 14445

Log Context

Log ”Scheduling reroute for delayed shards in [{}] ({} delayed shards)” classname is
We have extracted the following from Elasticsearch source code to get an in-depth context :

             } else {
                earlierRerouteNeeded = false;

            if (earlierRerouteNeeded) {
      "scheduling reroute for delayed shards in [{}] ({} delayed shards)"; nextDelay;
                DelayedRerouteTask currentTask = delayedRerouteTask.getAndSet(newTask);
                assert existingTask == currentTask || currentTask == null;
            } else {

About Opster

Opster identifies and predicts root causes of Elasticsearch problems, provides recommendations and can automatically perform various actions to prevent issues, optimize performance and save resources.

Learn more: Glossary | Blog| Troubleshooting guides | Error Repository

Need help with any Elasticsearch issue ? Contact Opster