Review Kubernetes Health Probes in Coding-Agent Patches

Last reviewed: November 7, 2026 (Asia/Shanghai); official references checked November 6 UTC.

Direct answer

A Kubernetes health probe review should compare the rendered probe configuration with the application code that answers it. Define three decisions separately: when initialization has completed, when the instance can serve requests, and when restarting the container can repair a local failure. Then test those decisions in a disposable environment using Pod conditions, container restart counts, probe events, and the matching Service’s EndpointSlices.

The Kubernetes probe reference distinguishes the consequences. A startup probe delays liveness and readiness checks until it succeeds. A readiness failure marks the container unready without restarting it. Startup or liveness failures reaching their configured threshold cause container termination, followed by the applicable restart policy. A coding-agent patch that replaces these checks with one dependency-sensitive endpoint can therefore turn a temporary backend outage into repeated restarts.

Who this is for

Use this workflow when a coding agent edits application health handlers, Kubernetes manifests, Helm values, or Kustomize overlays for a Service-backed workload. It is intended for maintainers reviewing ordinary application containers in a Deployment with restartPolicy: Always.

Give the agent the existing health contract and affected environments before asking for a repair. Ask it to propose a focused patch and acceptance checks. Run cluster changes through the team’s approved test deployment workflow, with synthetic data and an explicit context and namespace.

Key takeaways

• Review the endpoint implementation together with every rendered probe that calls it.
• A startup probe protects initialization; readiness does not delay liveness.
• Readiness failure changes traffic eligibility and keeps the container running.
• Liveness should detect a local failure that restarting can help resolve.
• Inspect EndpointSlice conditions and Service settings; an endpoint’s presence alone does not establish readiness.
• Require a healthy baseline, intentional failure cases, and recovery evidence before approving the patch.

Sources checked

Three primary Kubernetes references were retrieved successfully on November 6, 2026 UTC:

• Liveness, Readiness, and Startup Probes defines probe purposes, failure actions, configuration fields, HTTP success criteria, and the risk of cascading failures.
• Configure Liveness, Readiness and Startup Probes demonstrates configuration, startup allowances, named HTTP ports, and observing probe failures and restarts.
• EndpointSlices explains endpoint conditions, the Service-name label, and the publishNotReadyAddresses exception to ordinary readiness behavior.

These maintained technical references support an evergreen review task. The probe pages report a June 30, 2026 modification; the EndpointSlice page reports June 22, 2025. Match the documented behavior to the target cluster version. This guide uses established HTTP probe fields and reports no executed cluster tests or deployment results.

Contract details to verify

Define what each health result means

Write the expected application behavior before changing thresholds. A useful example contract is:

For a strict dependency, the readiness handler may check whether that dependency is usable while the liveness handler checks the application itself. This follows the distinction in the probe reference . Decide whether that dependency is truly required: an application that can serve a degraded response may need a different readiness contract.

Keep health checks cheap and bounded. They should observe health without performing a migration, expensive query, or state-changing operation. A liveness endpoint that always returns success cannot demonstrate that the request-processing path is making progress. Conversely, restarting every instance cannot repair a shared database outage.

Record the candidate revision, cluster version, rendered environment, container name, probe mechanism, endpoint implementation, timing values, restart policy, and matching Service. Include sidecars when they have probes or can affect overall Pod readiness.

Use the Pod security review guide when runtime restrictions also change. If the patch changes communication rules or workload labels, use the NetworkPolicy review guide to verify that separate contract.

Inspect the rendered configuration and handler together

Render every affected chart or overlay. Check each effective container’s probe path, port, scheme, thresholds, and timing. Compare these with the application routes and named container ports. A correct base manifest can be overridden by environment values, and an agent can rename a route without updating the manifest that calls it.

The following fragment belongs inside a Deployment’s container list. It assumes an existing reviewed image and an application listening on port 8080. Its /live handler returns failure until initialization completes, then checks local progress without depending on a shared backend. Its /ready handler additionally checks the strict serving requirements. Implement and test those handlers before using this configuration.

- name: api
  ports:
    - name: http
      containerPort: 8080
  startupProbe:
    httpGet:
      path: /live
      port: http
    periodSeconds: 5
    timeoutSeconds: 2
    failureThreshold: 30
    successThreshold: 1
  livenessProbe:
    httpGet:
      path: /live
      port: http
    periodSeconds: 10
    timeoutSeconds: 2
    failureThreshold: 3
    successThreshold: 1
  readinessProbe:
    httpGet:
      path: /ready
      port: http
    periodSeconds: 5
    timeoutSeconds: 2
    failureThreshold: 2
    successThreshold: 2

These values illustrate a reviewable policy, not recommended defaults for every application. The configuration walkthrough uses failureThreshold × periodSeconds to plan startup allowance. Here, 30 × 5 gives a nominal 150-second allowance. Choose the values from observed startup behavior and an agreed margin. Do not turn the multiplication into an exact wall-clock restart assertion: probe execution, timeouts, and shutdown grace also matter.

Startup and liveness require successThreshold: 1; readiness can require consecutive successes before recovering. The probe reference also notes that readiness checks may run more frequently while a container is unready. Measure recovery rather than assuming it takes exactly two configured periods.

HTTP probe success is determined by status codes from 200 through 399, not by a healthy-looking response body. Require a direct status from a dedicated route, such as 200 for success and 503 for the fixture’s unhealthy state. Check that authentication middleware or a route change does not redirect probes to a login page. A successful API validation cannot establish these handler semantics.

Verify traffic eligibility through the actual Service

Readiness controls normal matching Service traffic; it does not make an application unreachable through every possible path. The EndpointSlice reference defines ready, serving, and terminating conditions. An unready Pod can still have an endpoint entry, so inspect its conditions and associated Pod identity.

Check spec.publishNotReadyAddresses on the Service. When it is true, EndpointSlice ready is always true. The ordinary expectation that an unready instance stops receiving Service traffic is therefore unsuitable for that Service. Resolve the intended discovery and routing contract before approving the probe change.

For an authorized fixture labeled app=api and exposed by a Service named api, these read-only commands collect relevant observations. Replace the example context and namespace explicitly:

kubectl --context review-cluster --namespace agent-review \
  get pods -l app=api -o json |
  jq '[.items[] | {
    pod: .metadata.name,
    uid: .metadata.uid,
    conditions: [.status.conditions[]? |
      select(.type == "Ready") | {type, status}],
    containers: [.status.containerStatuses[]? |
      {name, ready, restartCount}]
  }]'

kubectl --context review-cluster --namespace agent-review \
  get service api -o json |
  jq '{name: .metadata.name,
       publishNotReadyAddresses: (.spec.publishNotReadyAddresses // false)}'

kubectl --context review-cluster --namespace agent-review \
  get endpointslices -l kubernetes.io/service-name=api -o json |
  jq '[.items[] | {
    slice: .metadata.name,
    endpoints: [.endpoints[]? |
      {pod: .targetRef.name, uid: .targetRef.uid, conditions}]
  }]'

Read all matching slices. Retain relevant probe events as well. Use Pod UID and container name to distinguish a container restart from a replacement Pod; a fresh Pod’s counter is a different observation. Compare counts before and after each case instead of assuming the initial count is zero.

Exercise the healthy path and intentional failures

Use a synthetic application fixture with test-only controls for initialization delay, dependency availability, and local progress failure. Keep those controls confined to the disposable environment. Establish that the unchanged healthy fixture becomes ready, answers a harmless request through the Service, and has stable restart counts.

Then change one condition at a time. Define bounded observation deadlines from the configured probes, startup allowance, shutdown grace, and the test environment. Record actual timestamps and diagnostics rather than accepting one immediate status snapshot.

For traffic checks, send fresh harmless requests through the actual Service and have the fixture identify which synthetic instance answered. Keep a healthy second backend as a positive control during the dependency case. After observing the readiness and routing update, verify that new test requests no longer reach the unready instance. Treat a request timeout alone as inconclusive: it can also mean the Service, client, or network failed.

For liveness, ensure the fixture remains alive long enough for the probe to cause termination. A process that exits by itself exercises restart policy without proving the liveness check worked. Retain the specific probe-failure and restart evidence. Restore the healthy fixture between cases and rerun the baseline after the last mutation.

Failure modes

Running is treated as ready. Inspect the Pod’s Ready condition, the affected container, and EndpointSlice conditions. A running process can remain unready.

Readiness is expected to protect startup from liveness. These checks are independent. Use a suitable startup probe when initialization needs protection.

A backend outage restarts every application instance. Remove shared-dependency checks from the local liveness decision when restarting cannot repair that dependency. Verify traffic withdrawal and recovery separately.

A login redirect makes a broken route look healthy. HTTP probe success includes redirect status codes. Require a direct health response and test the real middleware path.

A counter reset is recorded as recovery. A rollout may create another Pod. Bind observations to the original UID and identify replacement separately from container restart.

FAQ

Does every container need all three probes?

No. The application and recovery contract determine which probes help. Kubernetes notes that a process which reliably exits on unrecoverable failure may not need a liveness probe. Add each probe for a stated decision and test its consequence.

Is a successful TCP probe enough?

It proves that the target port accepts a connection. It does not establish that initialization completed or that the application can serve its required request class. Choose a mechanism that measures the intended health contract.

Can one HTTP endpoint serve startup and liveness?

Yes. The official walkthrough uses the same endpoint for both. Its behavior must support that choice, while the two probe configurations can have different failure tolerances. Readiness may need a separate decision about serving requirements.

Reader next step

Choose one coding-agent patch that changes a health handler or Kubernetes probe. Render its effective configuration, write the three health decisions, and run a healthy baseline plus the dependency-loss and local-progress failure cases. Attach the candidate revision, Pod identities, probe events, restart-count changes, EndpointSlice conditions, and recovery observations to the pull request. Approve only when the observed consequences match the stated contract.