Where to View Liveness and Readiness in Rancher: Probes, UI, and kubectl

In Rancher, liveness and readiness status appears in three primary places: the workload's pod list under the "Containers" column in the Rancher UI, the individual pod's detail page, and the Condition and Events tabs at both workload and pod level. Underneath, all of it derives from the Kubernetes probe status that kubelet reports into each Pod's status.containerStatuses fields. The UI is a rendered view of that API object, so kubectl against the downstream cluster always shows the same truth.

The distinction matters because the two probe types answer different questions and fail in different directions. A readiness probe controls whether a pod receives traffic from a Service. A liveness probe controls whether kubelet restarts the container. A pod can be Running and ready, Running but not ready, or Running and being restarted repeatedly for liveness failure while still passing readiness. Rancher surfaces all three states, but only if you know which column and which tab to read.

How the status data is produced

Kubelet runs probes on a schedule you define and records the outcome in the Pod's status object. Readiness results land in containerStatuses[].ready, a boolean, and in the pod's Ready condition. Liveness results are not stored as a persistent boolean; the failure manifests as a container restart, which increments containerStatuses[].restartCount and populates lastState.terminated with an exit code and reason. That asymmetry is the single most important mechanical fact for troubleshooting: readiness has a clean current-state field, liveness only has a historical trace.

Rancher's cluster agent streams and caches this data from the downstream cluster's API server. On a Rancher-managed cluster, you are almost always looking at cached objects, not a live query. Refresh latency depends on the agent's watch and cache sync, typically a few seconds, but a slow or disconnected agent can freeze the displayed state while the cluster keeps changing. The Professional caveat: always confirm in kubectl before acting on a restart loop that the UI shows as stable.

Environment variables and file-based probes behave differently at the mechanism level. An exec probe spawns a process inside the container namespace each period, so a heavy probe script adds CPU load proportional to periodSeconds. An httpGet probe opens a TCP connection from kubelet to the pod IP, which means it can fail for reasons unrelated to the app, including network policy, CNI issues, and sidecar interception. A tcpSocket probe only proves the port is bound, not that the app can serve. A grpc probe exists in current Kubernetes and is health-check-protocol aware, but support depends on the app implementing the standard service.

Quantified context: defaults, timeouts, and blast radius

The numbers decide behavior more than the probe type does. Default periodSeconds is 10, default timeoutSeconds is 1, and default failureThreshold is 3 for both probe types. That means a readiness probe fails after roughly 30 seconds of sustained failure, and a liveness probe restarts the container after the same window. A timeoutSeconds of 1 is aggressive for any probe that touches a database or does DNS resolution; raising it to 3-5 seconds is common in production and rarely changes detection latency meaningfully.

initialDelaySeconds interacts badly with slow-starting applications. If your app needs 90 seconds to warm a cache and you set an initial delay of 10, liveness will restart the container before it ever becomes healthy, and the restart count climbs indefinitely. A startupProbe with failureThreshold set so that periodSeconds × failureThreshold exceeds your worst-case boot time is the correct fix; once it succeeds, liveness and readiness take over.

Blast radius scales with replica count and probe type. A readiness failure on a 12-replica deployment removes one endpoint at a time and traffic shifts; users may see nothing. A liveness failure on the same deployment causes repeated restarts of individual pods, and if the failure is caused by a shared dependency, all 12 can enter a restart loop that saturates the node's CPU with container startup work. That failure amplification is why liveness probes should test the process, not its dependencies.

Reading the Rancher views, layer by layer

Start at Cluster Management, select the cluster, then Workloads, then Deployments (or StatefulSets, DaemonSets). The workload list shows a Ready column in the form "3/3", where the numerator is ready replicas and the denominator is desired. Hovering or clicking through to the workload detail page shows each pod with a Ready column of "2/2", one entry per container. A pod showing "1/2" is Running but not fully ready; the container that is not ready is the one whose readiness probe is failing.

Open the pod detail page for the decisive view. The Containers section lists each container with its state, restart count, and last termination reason. Below that, the Conditions panel shows Ready, ContainersReady, Initialized, and PodScheduled with status, reason, and last transition time. The Events tab at pod level is where probe failures appear as Unhealthy events with the probe type, the failing endpoint or command, and the message your app returned. Workload-level Events aggregate across pods and are useful for spotting a pattern across replicas.

The YAML tab on the pod detail page is the ground truth for configuration: it shows livenessProbe and readinessProbe blocks exactly as applied, including inherited defaults. Compare that to the workload's pod template if the values look wrong. Editing the template without triggering a rollout leaves existing pods running the old spec, a common source of confusion when a fix appears not to have taken effect.

Comparison: where each view helps and where it misleads

Edge cases that break the simple reading

Restart count is cumulative and never resets for the life of the pod object. A pod that restarted twice during a deployment rollout six days ago still shows 2, and a fresh reader may mistake that for an active problem. Compare lastState.terminated.finishedAt timestamps to distinguish historical from current failures.

Init containers and sidecars change the Ready math. A pod with an Istio or other service mesh sidecar shows "2/2" and requires both containers ready. If the sidecar's readiness gate is failing, the application container looks healthy in its own status while the pod never becomes Ready. The Conditions panel's ContainersReady will be False even though the app container's own readiness probe passes, which is the correct signal and frequently misread.

A pod in CrashLoopBackOff presents as Restarting with backoff in the waiting state, and Rancher's UI may show it as not ready with an empty Events tab if events have aged out of retention. Kubernetes uses exponential backoff starting at 10 seconds and doubling up to a 5-minute ceiling, so a pod can sit in a waiting state for minutes with nothing new in Events. The lastState.terminated fields, including exit code and reason, are the durable evidence.

Red flags to treat as real findings:

Restart count rising while the UI's workload view shows Ready replicas at full strength. Container state Restarting with a last termination reason of Error and no recent events. Pods showing Ready "1/2" with the app container ready and a sidecar not ready. initialDelaySeconds absent or shorter than the observed cold-start time. Liveness probe configured with an httpGet to a dependency-backed endpoint. The same probe message repeating across every replica within one minute.

Misconceptions worth correcting

A Running pod is not a ready pod. Running describes the container process state; Ready describes the probe verdict. Rancher shows both, and conflating them is the most common reading error on the platform.

The Rancher UI is not a monitoring system. It displays current cached state but keeps no probe history, no success rate, and no latency trend. Probe success rates and failure counts over time are metrics, exported by kubelet as probe_success and consumed by Prometheus. If you need to know whether a probe fails intermittently, the UI cannot tell you; the metrics pipeline can.

Liveness failure does not always mean the app is broken. An exec liveness probe that runs a shell command will fail if the shell binary is absent from a distroless image, and the container will restart forever while the application is perfectly healthy. A liveness probe pointed at an endpoint that depends on a shared database can restart every replica simultaneously during a database blip. That is a self-inflicted outage, not a resilience mechanism.

A readiness probe that never fails is a readiness probe that provides no protection. Probes written to return 200 unconditionally show green forever and hide partial failures. A probe that checks the app's ability to serve its actual traffic path, with a bounded timeout, is the useful version.

Practical actions: verifying and fixing in order

Confirm the displayed state against the cluster before changing anything: run kubectl get pods -o wide and kubectl describe pod , then compare Ready, restartCount, and lastState.terminated.finishedAt to the Rancher view. Read the failing probe configuration from the pod YAML tab, not the workload template, and note the effective timeoutSeconds, periodSeconds, and failureThreshold rather than the intended values. Set timeoutSeconds to at least 3 seconds for any probe that performs network I/O, and set initialDelaySeconds or a startupProbe window to exceed the measured cold-start time by a margin. Keep liveness probes shallow: test the process and its internal health, not downstream dependencies. Move dependency checks to readiness so traffic drains instead of containers restarting. Watch probe_success in Prometheus for a week after a change; a probe that only fails under load will not appear in the UI at all. Set failureThreshold and successThreshold deliberately: a readiness probe with successThreshold: 1 flaps faster than the default, and failureThreshold of 3 with a 10-second period means 30 seconds before traffic drains.

Limits of what the Rancher views can tell you

The views answer "is this pod ready and is it restarting" and little beyond that. They cannot distinguish a probe failure caused by the application from one caused by kubelet's network path, a CNI policy, or a slow DNS resolver. They do not retain history, so intermittent failures during low-traffic hours are invisible unless metrics are collected. They show the downstream cluster's state through the agent's cache, so a degraded connection can display stale readiness that no longer matches reality. For anything requiring causality or trend, you need the metrics and logs pipeline, and the UI becomes a starting point rather than an answer.

This article is general educational information about Kubernetes and Rancher observability, not a configuration standard, support agreement, or professional operations recommendation for any specific environment. Validate probe changes against your own failure modes and rollout procedures. For production incidents, consult your platform engineering team or the appropriate vendor support channel.