Give slow Kubernetes startup its own probe budget

Startup, liveness, and readiness checks answer different operational questions.

Source facts

Kubernetes startup probes allow an application time to initialize before liveness takes over. A startup probe can also be used to delay readiness checks. If the documented example’s startup probe never succeeds, the container is killed and is subject to the Pod’s restartPolicy. A Pod whose containers report not ready does not receive traffic through Kubernetes Services.

Source: Kubernetes documentation — Configure Liveness, Readiness and Startup Probes.

Applicability

Review the separate startup, liveness and readiness decisions before changing a container’s probe settings.

DSE recommendation

DSE recommends measuring normal and exceptional initialization before selecting a startup threshold. Write down what each endpoint proves: startup complete, process making progress, or ready to accept useful work. Avoid putting a remote dependency into liveness merely because it is convenient to check; decide separately how an unavailable dependency should affect traffic. Include a recovery path for failed initialization, and ensure the startup allowance fits the service’s operational expectations. Keep probe changes with the application configuration so a new image does not inherit unexplained timings.

Verification

In staging, test a normal start, an intentionally slow start, and a failed initialization. Observe probe events, restart count, and Service readiness. Confirm that an unready but running application is distinguished from one the kubelet must restart. Have the service owner identify a representative business request to attempt after readiness succeeds. Retain that result beside the probe events so endpoint success and useful service recovery remain separately observable.

Official reference

Kubernetes documentation — Configure Liveness, Readiness and Startup Probes. Reviewed October 20, 2026.