Introduction

Kubernetes liveness probes do not create a rich application-style log stream by themselves. The main places to look are Pod events, kubelet logs, and your application logs around the health-check path or command. If you need detailed probe diagnostics, you should design your probe target to emit useful logs rather than expecting Kubernetes to capture every detail automatically.

What Kubernetes Records by Default

When a liveness probe fails, Kubernetes records that failure as part of Pod lifecycle information. The fastest place to inspect it is kubectl describe pod.

kubectl describe pod my-app

In the event section you will typically see probe failure messages, restarts, and back-off behavior. You can also query events directly:

kubectl get events --field-selector involvedObject.name=my-app

These events are good for answering questions such as:

• did the liveness probe fail
• how often did it fail
• was the container restarted
• when did the restart happen

They are not a substitute for application logs.

Log the Health Check Path in the Application

If the probe is HTTP or gRPC based, the best detailed logging often comes from the application itself. Instrument the health endpoint so failures leave useful evidence in normal container logs.

1livenessProbe:
2  httpGet:
3    path: /health/live
4    port: 8080
5  initialDelaySeconds: 10
6  periodSeconds: 5
7  timeoutSeconds: 2

If the /health/live handler checks database access, thread pool exhaustion, or internal queue pressure, write those failure reasons to stdout or stderr in your application.

Then inspect the logs normally:

kubectl logs my-app

That gives you a far clearer story than “probe failed” alone.

Exec Probes Need Their Own Diagnostics

For an exec liveness probe, Kubernetes runs a command inside the container. Do not assume that command’s output will give you a durable, searchable probe log. If the command performs meaningful checks, make the script write explicit diagnostics somewhere visible, usually standard output from the main process or a dedicated log file that your container already exports.

1livenessProbe:
2  exec:
3    command:
4      - sh
5      - -c
6      - test -f /tmp/app-healthy
7  periodSeconds: 10

If you need deeper visibility, keep the command simple and log the real failure conditions from the application or helper script itself.

Use Kubelet Logs for Node-Level Debugging

When probe failures are hard to explain, the next level is the kubelet on the node that hosts the Pod. Kubelet logs can help when the problem is tied to node pressure, timeouts, networking, or probe execution behavior.

This is an operations-level troubleshooting step, not something most application developers need every day. But it is the right place to look when Pod events say probes are failing and application logs do not explain why.

Tune Probes to Reduce Noise

Sometimes the “logging problem” is really a configuration problem. A liveness probe that starts too early or times out too aggressively can generate misleading failure events.

Adjust these values carefully:

• 'initialDelaySeconds for slow starts'
• 'timeoutSeconds for endpoints that may briefly stall'
• 'failureThreshold for transient blips'
• 'periodSeconds for probe frequency'

Probe logs become much more useful when the probe definition matches the real startup and runtime behavior of the application.

Common Pitfalls

• Expecting liveness probes to produce a dedicated detailed log stream automatically.
• Looking only at container logs and forgetting Pod events.
• Using a health endpoint that returns failure but does not explain why in application logs.
• Making probes so aggressive that they create noisy restarts during normal startup.
• Treating readiness and liveness failures as identical operational signals.

Summary

• Liveness probe failures are primarily visible through Pod events and restart history.
• Use kubectl describe pod and kubectl get events first.
• Put detailed diagnostics in the application’s health endpoint or helper script logs.
• Check kubelet logs when the failure appears to be infrastructure-related.
• Tune probe timing so the signal is meaningful instead of noisy.