Heartbeat monitoring involves periodically sending a small signal—such as an HTTP request, TCP packet, or ICMP ping—from a monitored node or service to a monitoring system (or between peer nodes in a cluster) to confirm the system is alive and responsive.
How it works
A sender emits a heartbeat message at a fixed interval, typically every 1–30 seconds. The monitoring system records when each heartbeat arrives and compares the timestamp against a configured timeout window. If a heartbeat fails to arrive within that window (often after several consecutive missed intervals), the monitored node is marked as DOWN and automated actions trigger—such as sending an alert, failing over to a backup, or restarting the service.
Heartbeat monitoring can be unidirectional (an agent pushes heartbeats to a central monitor) or bidirectional (peer nodes in a cluster exchange heartbeats to detect failures among themselves).
Example
Kubernetes uses liveness probes as a heartbeat mechanism: the kubelet periodically sends HTTP or TCP checks to a container. If the probe fails a set number of times in a row, Kubernetes automatically restarts the container. Similarly, in high-availability clusters, nodes running Pacemaker exchange heartbeat messages over a dedicated network; when a node stops sending heartbeats, the cluster triggers failover of its services to a healthy peer.
When it matters
Heartbeat monitoring is essential for uptime monitoring, load balancer health checks, and cluster failover automation. It enables rapid detection of failed services and automated recovery.
WarningSplit-brain risk: A missed heartbeat can signal either that the monitored node has crashed OR that the network link carrying the heartbeat has failed. The node may still be serving traffic even if heartbeats are lost. In production high-availability clusters, heartbeat monitoring is always paired with quorum mechanisms and fencing (STONITH) to prevent two nodes from simultaneously claiming primary status.