Those decisions depend on application behavior. An endpoint named /health does not tell the model whether it checks the process, a database or both.
Describe the failure before selecting a probe
This fictional service exposes three endpoints with deliberately different contracts:
| Endpoint | Supplied behavior | Intended use |
|---|---|---|
| /started | Succeeds after local initialization completes | Startup probe |
| /live | Fails when the process is irrecoverably stuck | Liveness probe |
| /ready | Fails when the service cannot accept work, including temporary dependency loss | Readiness probe |
The endpoint behavior is an assumption for this exercise. Verify it in the application source and test environment before using the same paths in a workload.
Kubernetes' probe documentation, checked October 24, 2026, distinguishes these mechanisms. A failing readiness probe affects ready traffic endpoints. A liveness failure reaching its threshold triggers a container restart. When configured, the startup probe must succeed before liveness and readiness probes begin.
Review an illustrative container fragment
ports:
- name: http
containerPort: 8080
startupProbe:
httpGet:
path: /started
port: http
periodSeconds: 5
failureThreshold: 24
livenessProbe:
httpGet:
path: /live
port: http
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: http
periodSeconds: 5
failureThreshold: 2
This fragment belongs under one container in a valid Pod template. It omits the workload wrapper, image and resource settings, and it is not a complete deployable manifest. The timings are illustrative choices for the stated exercise, not measured settings for your application or an exact promise of elapsed restart time.
Suppose the database temporarily becomes unavailable after startup. Under the supplied endpoint contracts, /ready fails while /live stays successful. The service loses readiness after the configured failure threshold, but the liveness mechanism does not restart it for that dependency failure. If all probes point at an endpoint that fails whenever the database does, the same event can instead provoke restarts that do not repair the database.
Whether removing all traffic is appropriate also depends on the real application. A service that can still fulfill some requests needs an explicit readiness policy, not a guessed all-or-nothing rule.
Ask for consequences and evidence
Review probes for this Kubernetes workload before changing them.
Relevant workload manifest and Kubernetes version: [PASTE]
Each endpoint's actual checks, success/failure responses and port: [PASTE]
Observed startup duration and failure symptoms: [PASTE OR UNKNOWN]
Expected behavior during dependency failure and recovery: [ENTER]
Relevant container events, restart counts and readiness observations: [PASTE]
Explain readiness, liveness and startup consequences separately.
Map each proposed probe to an established endpoint contract. Identify
missing evidence instead of inventing endpoints or timing targets.
Return a minimal container-level patch and tests for startup, temporary
dependency loss and recovery. Do not apply manifests or claim those
tests ran. Preserve unrelated workload and access settings.
The context-first approach follows OpenAI's prompting guidance. In this case the endpoint implementation is more useful than an isolated screenshot of a failing Pod.
In the approved test environment, compare endpoint responses, readiness transitions and restart counts for each scenario. Record the observed recovery as well as the failure. For missing files inside the container, the Docker path guide investigates a separate cause. Accept probe settings only after the observed behavior matches the service's intended traffic and restart policy.