Kubernetes uses node heartbeats to assess whether a node is available, while readiness probes tell it whether a container should receive traffic. They are different signals with different observers and outcomes: a Node Lease helps the control plane track node liveness; a failed readiness probe makes a Pod unready without restarting its container. Liveness probes are separate again: repeated failures can trigger a container restart.
What each Kubernetes health signal checks
“Kubernetes node health checks” can refer to more than one mechanism. Node status and Node Lease heartbeats are node-level availability signals. Readiness and liveness probes are container-level checks run by the kubelet. A node can be healthy while one of its containers is not ready for traffic, and a node can stop reporting even though application readiness is a separate question.
| Signal | Scope and meaning | How it is updated or checked | Consequence |
|---|---|---|---|
| Node status heartbeat | Node-level status and conditions, including Ready | The kubelet posts Node status when it changes or at a configured interval | The node controller uses availability information to detect failures and act |
| Node Lease heartbeat | Lightweight indication of a particular node’s liveness | The kubelet creates or renews the Node’s Lease in kube-node-lease, independently of Node status updates |
Helps determine node availability with less update impact in large clusters |
| Node Ready condition | Whether a node is healthy and ready to accept Pods | Reported as part of Node status; the controller can report Unknown after its monitoring grace period | Describes node-level availability, not whether an individual application container is ready |
| Readiness probe | Whether a container is ready to accept traffic | The kubelet periodically runs the configured probe | A failed check makes the Pod unready and removes its IP from matching Service EndpointSlices; it does not restart the container |
| Liveness probe | Whether a container should be considered unhealthy and restarted | The kubelet periodically runs the configured probe | Failures reaching the configured threshold can cause the kubelet to restart that container |
How kubelet heartbeats and node leases work
Kubernetes documents two forms of node heartbeat: updates to a Node’s .status and Lease objects associated with Nodes. Each Node has an associated Lease in the kube-node-lease namespace. The kubelet sends the signals; the control plane uses node availability information to reason about node health.
A Lease is lightweight compared with a full Node status update. Kubernetes uses Lease renewals to reduce the performance impact of frequent updates in large clusters. Lease updates occur independently of Node status updates, so they should not be treated as the same stream or assumed to share one interval.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
What Node Ready means
The Node Ready condition represents whether Kubernetes considers the node healthy and able to accept Pods. In the Kubernetes v1.35 Node Status reference, Unknown means the controller has not heard from the node within node-monitor-grace-period; that reference lists 50 seconds as the default. This is a documented default for that reference, not a guarantee for every version or managed cluster.
Loss of heartbeats indicates an availability problem, but it does not establish one universal time at which Pods will be evicted. The eventual response depends on controller timing, node conditions and taints, Pod tolerations, release, and cluster configuration.
What readiness and liveness probes do
Readiness controls traffic eligibility
A readiness probe answers whether a container is ready to accept traffic. When readiness fails, the container continues running and the kubelet continues probing it. The Pod’s Ready condition becomes false, and its IP is removed from EndpointSlices for Services that select it. When the check succeeds again, the Pod can become eligible for traffic again.
Liveness can trigger a restart
A liveness probe answers a different question: whether the container should be restarted. Once consecutive failures reach the configured failureThreshold, the kubelet can restart that container. Liveness is not a traffic-routing control; readiness is not a restart mechanism.
Rank #3
Choose checks based on the action Kubernetes should take. Readiness should represent an application-specific ability to serve traffic. Liveness should indicate a condition from which the container cannot recover without a restart. A liveness check that fails during temporary overload can trigger restarts, increase pressure on remaining Pods, and worsen an outage.
Startup probes protect slow initialization
A startup probe can delay the start of liveness and readiness checks until an application has initialized. This prevents those checks from acting on a slow-starting application before startup has completed.
Probe mechanisms and configuration defaults
Kubernetes documents HTTP, TCP, exec, and gRPC probe mechanisms. Readiness and liveness probes can use similar mechanisms or endpoints, but their consequences differ, so configure each for its intended purpose.
| Probe field | Documented default | What it controls |
|---|---|---|
periodSeconds |
10 seconds | How often the kubelet performs the probe |
timeoutSeconds |
1 second | How long a probe may take before it times out |
successThreshold |
1 | Consecutive successes needed to consider the probe successful |
failureThreshold |
3 | Consecutive failures before the configured failure action applies |
These are probe-configuration defaults in Kubernetes documentation. A threshold is not the same as end-to-end time until an action: actual timing also depends on when probe executions are scheduled, how long they take, and any configured termination grace period.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Node heartbeat timing: interpret defaults by version
Kubernetes’ v1.35 Node Status reference describes a default Lease update interval of 10 seconds. It also describes retries for Lease update failures using exponential backoff starting at 200 milliseconds and capped at 7 seconds. For Node status updates when no status change occurs, that same page gives a five-minute default interval.
The kubelet command reference lists a 10-second default for --node-status-update-frequency and cautions that it must work with the node controller’s nodeMonitorGracePeriod. That flag reference and the v1.35 Node Status page describe different aspects of Node status update behavior; do not combine them into one universal interval. Check the documentation for your Kubernetes release and the effective kubelet and controller configuration. Managed Kubernetes providers may set or constrain values differently.
Quick Recap
Which signal should you investigate?
- A node is reported unavailable or its Ready condition changes: inspect Node status, its Lease in
kube-node-lease, controller timing, and the cluster’s effective grace-period and node lifecycle settings. - A Pod is running but not receiving Service traffic: inspect its readiness probe result and Pod Ready condition, then check whether its IP appears in the relevant Service EndpointSlices.
- A container keeps restarting: inspect liveness probe failures and thresholds; do not assume a readiness failure caused the restart.
- A slow-starting application fails checks during initialization: consider whether a startup probe should gate readiness and liveness checks.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
