Spring Boot startup timeline: measure context work before extending probes

Measure the phase that is slow

A receipt service starts slowly after a new cache client and a schema check are added. A large readiness delay hides the symptom but also delays healthy replacements. Boot's BufferingApplicationStartup records startup steps for inspection; with Actuator configured, an operations-only startup endpoint can expose the timeline. This is diagnostic data about the application internals, so place it behind the same controlled management access as other operational endpoints. Startup validation should still fail promptly for a required invalid setting.

Keep the buffer bounded

The startup recorder retains a finite number of steps. Allocate enough capacity for one representative startup without making an unlimited in-memory log. Compare cold and warm starts and record the external systems contacted by slow bean constructors. A slow step may include network wait, class loading or a dependency chain; the timing alone does not prove the root cause. Early bean creation and lazy initialization change when work occurs, not necessarily how much work exists.

Test deployment readiness separately

Measure from process start to listener bind and from listener bind to readiness acceptance. A context may start while a required data migration or worker lease is still unavailable. Tune the platform startup probe from observed worst-case starts with margin, and keep liveness from killing a merely slow process. Readiness decides traffic admission; it cannot make a slow dependency fast. Re-run the timeline after each fix so an apparent gain is not just deferred work moved onto the first customer request.

Implementation contract

SpringApplication receiptApp = new SpringApplication(ReceiptApi.class);
receiptApp.setApplicationStartup(new BufferingApplicationStartup(1536));
receiptApp.run(args);

Cost and verification

Buffering retains step records during startup and adds small instrumentation work. Exposing the timeline adds an operational endpoint and access-control duty; deferring initialization may lower startup time while increasing first-request latency.

Common Mistakes

• Do not respond to every slow startup by extending the liveness deadline.
• Do not expose startup internals on a public management route.
• Do not call deferred initialization a performance gain without measuring the first request.

Read next

Spring Boot configuration validation: reject an unusable relay before work starts, Spring BeanPostProcessor: instance callbacks and the early-bean trap, Spring @Lazy singleton: failure moves from context refresh to first use, Spring readiness: report an unavailable dependency without forcing liveness failure, Spring Actuator management port: separate listener, explicit access rule.

Related Boot contract

Spring Boot layered jar: keep dependency changes out of the application layer.