Troubleshooting Eureka Delayed Registration: Causes and Fixes

Eureka provides a delayed registration feature that postpones service registration after startup to allow other frameworks or business code to finish initializing, preventing early call errors.

The delay relies on two configuration properties:

eureka.client.initial-instance-info-replication-interval-seconds

(initial delay) and eureka.client.instance-info-replication-interval-seconds (subsequent sync interval). By default they are 40 seconds and 30 seconds respectively.

eureka.client.initial-instance-info-replication-interval-seconds=40 // default 40 seconds
 eureka.client.instance-info-replication-interval-seconds=30 // default 30 seconds

Examining the source, DiscoveryClient.initScheduledTasks creates a scheduled task that calls start after the initial delay, achieving the delayed registration effect.

The first issue discovered was that InstanceInfoReplica directly terminates the thread‑pool task and invokes run, bypassing the delay. Additionally, when eureka.client.healthcheck.enabled=true, a HealthCheckHandler is created, which can trigger immediate registration via registerHealthCheck and onDemandUpdate.

@RestController
public class ControllerTest {
    @Autowired
    private HealthChecker healthChecker;

    @RequestMapping("/change")
    public String test(Boolean flag) {
        healthChecker.setUp(new AtomicBoolean(flag));
        return "success";
    }
}

@Component
public class HealthChecker extends EurekaHealthIndicator implements HealthIndicator {
    private AtomicBoolean up = new AtomicBoolean(true);

    public HealthChecker(EurekaClient eurekaClient, EurekaInstanceConfig instanceConfig, EurekaClientConfig clientConfig) {
        super(eurekaClient, instanceConfig, clientConfig);
    }

    @Override
    public Health health() {
        if (up.get()) {
            return Health.up().build();
        } else {
            return Health.down().build();
        }
    }
}

The second issue involved the DiscoveryClient registering a status‑change listener that calls onDemandUpdate when the instance status changes, again causing immediate registration. The relevant property onDemandUpdateStatusChange defaults to true.

Verification was performed by setting both eureka.client.healthcheck.enabled and eureka.client.onDemandUpdateStatusChange to false and increasing the delay values to very large numbers:

eureka.client.healthcheck.enabled=false
 eureka.client.onDemandUpdateStatusChange=false
 eureka.client.initial-instance-info-replication-interval-seconds=9999999 // default 40 seconds
 eureka.client.instance-info-replication-interval-seconds=999999 // default 30 seconds

Despite these changes, the service still registered after a few seconds because the heartbeat thread triggers registration when it receives a NOT_FOUND response.

Further analysis showed three registration entry points: the initial injection of DiscoveryClient, the heartbeat renew method, and a direct call to register. The heartbeat’s registry.renew ultimately calls AbstractInstanceRegistry, which, lacking instance information, returns NOT_FOUND and forces registration.

Consequently, even with the delay configured to a large value, the heartbeat (default every 30 seconds) limits the effective delay to around 30 seconds.

In summary, the delayed registration does not work by default because the event listener is enabled ( true) and the service registers immediately after startup. To make the delay effective, both eureka.client.healthcheck.enabled and eureka.client.onDemandUpdateStatusChange must be set to false, but the heartbeat will still cause registration within 30 seconds.