Probe types and configuration
Pod lifecycle overview · Checklist and references
Kubernetes Probe Deep Dive
Three Probe Types and How They Work
Kubernetes provides three types of probes to monitor Pod health.
Table 1. Purpose and behavior of the three probe types
| Probe type | Purpose | Action on failure | Activation timing |
|---|---|---|---|
| Startup Probe | Verify that application initialization is complete | Terminate the container and restart according to restartPolicy (when failureThreshold is reached) | Immediately after Pod startup |
| Liveness Probe | Detect application deadlocks | Restart the container | After the Startup Probe succeeds |
| Readiness Probe | Verify readiness to receive traffic | Remove from Service Endpoints (no restart) | After the Startup Probe succeeds |
Startup Probe: Protecting Applications with Slow Startup
A Startup Probe delays Liveness and Readiness Probes until the application has fully started. It is recommended when initialization takes longer than the Liveness Probe can tolerate through its initialDelaySeconds and failureThreshold. Applications with slow startup, such as Spring Boot applications, JVM applications, and applications that load ML models, are typical candidates; whether one is actually needed depends on the measured initialization time and the Liveness Probe configuration rather than on the framework.
How it works:
- Liveness and Readiness Probes remain disabled while the Startup Probe is running.
- Startup Probe succeeds → Liveness and Readiness Probes are enabled.
- Startup Probe fails (failureThreshold is reached) → the container restarts.
Liveness Probe: Detecting Deadlocks
A Liveness Probe checks whether the application is alive. If it fails, kubelet restarts the container.
Use cases:
- Detecting infinite loops and deadlocks
- Unrecoverable application errors
- Unresponsiveness caused by memory leaks
Cautions:
- Do not include external dependencies (such as a database or Redis) in a Liveness Probe.
- An external service failure can cause a cascading failure in which all Pods restart.
Readiness Probe: Controlling Incoming Traffic
A Readiness Probe checks whether a Pod is ready to receive traffic. If it fails, the Pod is removed from the Service's Endpoints, but the container does not restart.
Use cases:
- Checking connections to dependent services (databases and caches)
- Verifying that initial data loading is complete
- Gradually receiving traffic during deployment
Flow summary
- After the Init Container and main container start, the Startup Probe verifies that initialization is complete.
- The Liveness Probe determines whether to restart the container, and the Readiness Probe determines whether the Pod participates in Service Endpoints.
- Following a termination request, the container terminates after preStop execution, SIGTERM handling, and graceful shutdown.
Figure 1. Pod lifecycle and probe behavior flow
Probe Mechanisms
Kubernetes supports four probe mechanisms.
Table 2. Characteristics and suitable use cases by probe mechanism
| Mechanism | Description | Advantages | Disadvantages | Suitable use cases |
|---|---|---|---|---|
| httpGet | Send an HTTP GET request and check for a 200-399 response code | Standard approach, straightforward implementation | Requires an HTTP server | REST APIs, web services |
| tcpSocket | Check whether a connection to a TCP port can be established | Lightweight and fast | Cannot validate application logic | gRPC, databases |
| exec | Run a command inside the container and check for exit code 0 | Flexible, supports custom logic | High overhead | Batch workers, file-based checks |
| grpc | Use the gRPC Health Check Protocol (GA in K8s 1.27+) | Native gRPC support | Limited to gRPC applications | gRPC microservices |
httpGet Example
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: HealthCheck
scheme: HTTP # Or HTTPS
initialDelaySeconds: 30
periodSeconds: 10
tcpSocket Example
livenessProbe:
tcpSocket:
port: 5432 # PostgreSQL
initialDelaySeconds: 15
periodSeconds: 10
exec Example
livenessProbe:
exec:
command:
- /bin/sh
- -c
- test -f /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
grpc Example (Kubernetes 1.27+)
livenessProbe:
grpc:
port: 9090
service: myservice # Optional
initialDelaySeconds: 10
periodSeconds: 5
gRPC services must implement the gRPC Health Checking Protocol. Use google.golang.org/grpc/health for Go and the io.grpc:grpc-services artifact's io.grpc.protobuf.services.HealthStatusManager for Java.
Probe Timing Design
Probe timing parameters determine the balance between failure detection speed and stability.
Table 3. Default values and recommended ranges for probe timing parameters
| Parameter | Description | Default | Recommended range |
|---|---|---|---|
initialDelaySeconds | Wait time between container startup and the first probe | 0 | 10-30s (can be 0 when using a Startup Probe) |
periodSeconds | Interval between probe executions | 10 | 5-15s |
timeoutSeconds | Wait time for a probe response | 1 | 3-10s |
failureThreshold | Number of consecutive failures required to declare failure | 3 | Liveness: 3, Readiness: 1-3, Startup: 30+ |
successThreshold | Number of consecutive successes required to declare success (must be 1 for Liveness and Startup; only Readiness may use a value greater than 1) | 1 | 1-2 |
Timing Design Formulas
Approximate consecutive failure detection budget = failureThreshold × periodSeconds
Approximate minimum recovery time = (successThreshold - 1) × periodSeconds (additional intervals after the first success)
Examples:
failureThreshold: 3, periodSeconds: 10→ a consecutive failure detection budget of approximately 30 secondssuccessThreshold: 2, periodSeconds: 5→ recovery is declared about 5 seconds after the first success (Readiness only)
Recommended Timing by Workload
Table 4. Recommended probe timing settings by workload type
| Workload type | initialDelaySeconds | periodSeconds | failureThreshold | Rationale |
|---|---|---|---|---|
| Web services (Node.js, Python) | 10 | 5 | 3 | Fast startup, requires rapid detection |
| JVM applications (Spring Boot) | 0 (with a Startup Probe) | 10 | 3 | Slow startup, protected by a Startup Probe |
| Databases (PostgreSQL) | 30 | 10 | 5 | Long initialization time |
| Batch workers | 5 | 15 | 2 | Periodic tasks, less aggressive detection |
| ML inference services | 0 (Startup: 60) | 10 | 3 | Long model loading time |