Design startup, liveness, and readiness probes as separate signals so slow initialization, dead processes, and temporary traffic unavailability receive different responses.

What you will be able to do

Distinguish startup probe from liveness probe in a realistic probes and application health case.
Interpret the operational evidence and boundary associated with readiness probe.
Choose an appropriate action involving probe handler without exceeding the named workload scope.
Verify traffic outcome through an observable runtime result and reproducible handoff.

Frame Probes and Application Health

Design startup, liveness, and readiness probes as separate signals so slow initialization, dead processes, and temporary traffic unavailability receive different responses.

An API needs ninety seconds to load data, sometimes deadlocks afterward, and must leave Service endpoints briefly while refreshing its cache.

Keep declared state, runtime state, observable evidence, access boundaries, and recovery outcomes separate. Begin with the smallest read-only inspection that identifies the exact image, container, Pod, controller, network, storage object, or policy in scope.

Startup probe

A startup probe can delay liveness and readiness evaluation until application startup succeeds. Within probes and application health, this role answers one specific container or orchestration question and keeps its own evidence.

Set the startup window from measured worst-case initialization time. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not let liveness kill a healthy but still-starting application. The observable result is specific: normal initialization succeeds before the startup budget expires.

Liveness probe

A liveness probe indicates whether a container is functioning well enough to continue running. Within probes and application health, this role answers one specific container or orchestration question and keeps its own evidence.

Use a bounded check that detects the known deadlock. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not make liveness depend on an optional remote dependency outage. The observable result is specific: a deadlocked container fails liveness and is restarted.

Readiness probe

A readiness probe indicates whether a container should receive traffic through matching Services. Within probes and application health, this role answers one specific container or orchestration question and keeps its own evidence.

Report not ready while the cache refresh makes responses unsafe. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not use readiness failure as an automatic container restart request. The observable result is specific: the pod leaves and later rejoins ready endpoints.

Probe handler

Probe handlers execute a configured protocol or command against the container. Within probes and application health, this role answers one specific container or orchestration question and keeps its own evidence.

Choose the simplest supported handler that proves the intended condition. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not require authentication secrets that the probe cannot provide safely. The observable result is specific: the handler returns the expected success and failure states.

Traffic outcome

Combined probe behavior should allow startup, replace deadlocked processes, and protect user traffic during temporary unavailability. Within probes and application health, this role answers one specific container or orchestration question and keeps its own evidence.

Observe Pod conditions, restart count, endpoints, and user requests together. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not approve probes from isolated command success alone. The observable result is specific: requests reach only ready replicas throughout the scenario.

Apply Probes and Application Health to One Workload

Use one bounded workload decision: An API needs ninety seconds to load data, sometimes deadlocks afterward, and must leave Service endpoints briefly while refreshing its cache.

First, set the startup window from measured worst-case initialization time. Then, use a bounded check that detects the known deadlock. Preserve both observations with the exact resource identity before changing runtime state.

Next, report not ready while the cache refresh makes responses unsafe. After that, choose the simplest supported handler that proves the intended condition. Close the task only after you observe pod conditions, restart count, endpoints, and user requests together.

Recap Before Practice and Prove

Startup probe: A startup probe can delay liveness and readiness evaluation until application startup succeeds. In this workload, set the startup window from measured worst-case initialization time. Preserve the boundary: do not let liveness kill a healthy but still-starting application.

Liveness probe: A liveness probe indicates whether a container is functioning well enough to continue running. In this workload, use a bounded check that detects the known deadlock. Preserve the boundary: do not make liveness depend on an optional remote dependency outage.

Readiness probe: A readiness probe indicates whether a container should receive traffic through matching Services. In this workload, report not ready while the cache refresh makes responses unsafe. Preserve the boundary: do not use readiness failure as an automatic container restart request.

Probe handler: Probe handlers execute a configured protocol or command against the container. In this workload, choose the simplest supported handler that proves the intended condition. Preserve the boundary: do not require authentication secrets that the probe cannot provide safely.

Traffic outcome: Combined probe behavior should allow startup, replace deadlocked processes, and protect user traffic during temporary unavailability. In this workload, observe pod conditions, restart count, endpoints, and user requests together. Preserve the boundary: do not approve probes from isolated command success alone.