Kubernetes Startup Probe Behavior

Kubernetes Startup Probe Behavior is the set of rules governing how the kubelet uses a startupProbe to determine when a container has finished its own internal initialization, and how that determination gates the activation of liveness and readiness probing for the same container. Its defining role is protective: it exists specifically to prevent slow-starting applications from being killed by an impatient liveness probe before they have ever had a fair chance to become healthy.

The Problem It Solves

Conflicting Requirements Without It

Before startup probes existed, operators configuring a liveness probe for an application with a long, variable initialization time (large cache warm-up, slow migrations, cold-start compilation) faced a dilemma: a short initialDelaySeconds risked killing the container mid-startup, while a long one left genuinely deadlocked containers running unnoticed for that same extended window. A startup probe resolves this by separating the two concerns entirely.

containers:
  - name: app
    startupProbe:
      httpGet:
        path: /startupz
        port: 8080
      failureThreshold: 30
      periodSeconds: 2
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 10
      failureThreshold: 3

Execution Order

Startup Probe Runs First and Alone

While a startupProbe is defined and has not yet succeeded, the kubelet does not evaluate livenessProbe or readinessProbe at all for that container. The startup probe runs on its own periodSeconds interval, independent of the timing configured for the other two probe types.

Wide Effective Grace Period

The combination of periodSeconds and failureThreshold on the startup probe defines the maximum time an application is allowed to initialize: in the example above, up to sixty seconds (thirty attempts at two-second intervals) before the container is considered to have failed startup.

Failure Behavior

Treated Like a Liveness Failure

If the startup probe never succeeds within its allotted attempts, the kubelet kills the container exactly as it would for a liveness probe failure, restarting it according to restartPolicy. This means a container that consistently fails to start within the configured window enters the same CrashLoopBackOff pattern as one that starts but then deadlocks.

lastState:
  terminated:
    reason: Error
    exitCode: 1
restartCount: 2

Success Behavior

One-Time Transition

Once the startup probe succeeds a single time (successThreshold for startup probes is fixed at one and not configurable), the kubelet permanently stops executing it for the remaining life of that specific container instance and begins evaluating liveness and readiness probes from that point forward, each on their own independent schedules.

status:
  containerStatuses:
    - name: app
      started: true
      ready: true

The started field in container status specifically reflects whether the startup probe (or, if none is configured, the container's own process start) has completed.

Absence of a Startup Probe

Default Behavior

If no startupProbe is declared, started is considered true as soon as the container process begins, and liveness and readiness probes follow their own initialDelaySeconds independently without any additional gating.

Startup Probe Flow Diagram

This one-way gate is what allows applications with unpredictable but bounded startup times to use aggressive, sensitive liveness thresholds once running, without those same thresholds causing false-positive kills during the initialization window itself.