# Give slow Kubernetes startup its own probe budget

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

- Canonical URL: https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:14:43+00:00
- Modified: 2026-10-20T18:34:31+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-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](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). Reviewed October 20, 2026.

## Primary reference

- Name: Kubernetes documentation — Configure Liveness, Readiness and Startup Probes
- Authority: kubernetes.io
- URL: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Give slow Kubernetes startup its own probe budget,” DSE Security, https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.