In repmgr.conf, set its priority to a value of 0; apply the changed setting with repmgr standby register --force.

Additionally, if failover is set to manual, the node will never be considered as a promotion candidate.

repmgrd can monitor delayed standbys - those set up with recovery_min_apply_delay set to a non-zero value in recovery.conf - but as it's not currently possible to directly examine the value applied to the standby, repmgrd may not be able to properly evaluate the node as a promotion candidate.

We recommend that delayed standbys are explicitly excluded from promotion by setting priority to 0 in repmgr.conf.

Note that after registering a delayed standby, repmgrd will only start once the metadata added in the primary node has been replicated.

Configure your system's logrotate service to do this; see Section 13.4.

Check you registered the standby after recloning. If unregistered, the standby cannot be considered as a promotion candidate even if failover is set to automatic, which is probably not what you want. repmgrd will start if failover is set to manual so the node's replication status can still be monitored, if desired.

promote_command or follow_command can be user-defined scripts, so repmgr will not apply pg_bindir even if excuting repmgr. Always provide the full path; see Section 13.1.1 for more details.

repmgrd does this to avoid starting up on a replication cluster which is not in a healthy state. If the upstream is unavailable, repmgrd may initiate a failover immediately after starting up, which could have unintended side-effects, particularly if repmgrd is not running on other nodes.

In particular, it's possible that the node's local copy of the repmgr.nodes copy is out-of-date, which may lead to incorrect failover behaviour.

The onus is therefore on the adminstrator to manually set the cluster to a stable, healthy state before starting repmgrd.