Heartbeat Touch¶
Liveness protocol — instantiates Threshold-Refresh State Maintenance
Emits a small, regular liveness signal — a touched timestamp — so a monitor can tell the sender is still alive and treat its silence as failure.
The state maintained here is a registration of liveness held by an observer — a record, somewhere, that says "this participant is still here." Heartbeat Touch keeps that record fresh by periodically touching it: updating a last-seen timestamp or renewing an ephemeral entry that a monitor watches. Its defining feature, and what separates it from a mere keepalive, is that the signal is watched, and its absence is meaningful: if the touches lapse past a deadline, the monitor flips the sender from alive to dead and triggers recovery — reassignment, failover, re-election. The heartbeat does no application work at all; its entire value is being a trace that something is watching, and its silence is a trigger.
Example¶
In a distributed job scheduler, each worker node touches its entry in the coordinator every ≈5 seconds, refreshing a last-seen timestamp. The coordinator never has to reach out to the workers — it simply watches the timestamps. If a worker's heartbeat lapses for, say, three intervals, the coordinator declares it dead, reassigns the jobs it was holding, and routes no new work to it. The touch itself carries no results and computes nothing; it exists only so that a stopped touch becomes an unambiguous, observable event. Each worker owns and emits its own beat, so liveness is self-reported and the coordinator's job is reduced to reading a clock.
How it works¶
Each participant periodically touches a shared or observed record — not a point-to-point ping the peer must acknowledge, but an update to state the monitor already reads. That record is the liveness evidence. A deadline expressed as a missed-beat count defines death: fall silent past it and you are declared failed, which fires a recovery rule — failover, job reassignment, fencing of the suspect node. Because each participant emits its own beat, ownership of the refresh is distributed to the thing whose liveness is in question.
Tuning parameters¶
- Heartbeat interval — shorter detects failure faster but adds overhead and raises the false-positive rate; longer is cheaper but slows detection. The core detection-latency dial.
- Failure threshold — how many missed beats before the sender is declared dead. Tighter catches real failures sooner but flaps on transient hiccups; looser is stable but sluggish.
- Recovery / fencing action — what a declared death triggers, and whether a wrongly-suspected node is forcibly fenced so it cannot keep acting.
- Clock and skew tolerance — how much timing drift between emitter and monitor is absorbed before a beat is counted late.
When it helps, and when it misleads¶
It is the workhorse of failure detection and membership in systems where you cannot tell a crashed node from an unreachable one except by its silence. Its hard failure mode follows from that same fact: a slow-but-alive node — mid garbage-collection pause, or on the far side of a network partition — can miss its beats and be wrongly declared dead while it is still acting, producing split-brain or double execution. The impossibility of perfectly distinguishing "slow" from "dead" over a timeout is fundamental, not a tuning bug.[n1] The classic misuse is shortening the interval "to detect faster" until every transient hiccup causes a needless failover. The discipline is to pair the detector with fencing, so that a node wrongly declared dead is actually prevented from continuing.
How it implements the components¶
refresh_action— the periodic touch that updates the liveness record.refresh_cadence— the heartbeat interval, tuned against detection latency and overhead.evidentiary_trace— the last-seen timestamp or registration is the observable proof of liveness the monitor reads.lapse_recovery_rule— a missed-beat deadline defines death and fires failover, reassignment, or fencing.refresh_owner— each participant emits and owns its own beat, so liveness is self-reported.
It does not model a data-freshness half-life or expiry clock (that is Cache TTL Refresh), nor take the refresh's own network cost as its defining constraint (Keepalive Signal).
Related¶
- Instantiates: Threshold-Refresh State Maintenance — the liveness case, where a lapsed refresh is itself the signal to act.
- Consumes: a monitor or coordinator that watches the trace; a fencing mechanism to make recovery safe.
- Sibling mechanisms: Keepalive Signal · Lease Renewal · Cache TTL Refresh · Refresh Validity Probe · Attention Refresh Pulse · Checklist Micro-Rehearsal · Reminder Ping · Rolling Context Refresh · Subvocal Repetition Loop
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Heartbeat Touch operates as an ongoing sensing arrangement that repeatedly observes actual state and surfaces changes or alerts because it emits a small, regular liveness signal — a touched timestamp — so a monitor can tell the sender is still alive and treat its silence as failure
Independent corroboration: The frozen evidence defines Heartbeat Touch as 'Emits a small, regular liveness signal — a touched timestamp — so a monitor can tell the sender is still alive and treat its silence as failure', so its operative form is Monitoring, Sensing & Alerting.
Nearest alternative: Control, Automation & Runtime — The touch supplies a recurring liveness observation, while any automatic response sits in a downstream monitor.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Timestamp touching as a liveness signal belongs to distributed systems and software operations, where failure detectors infer faults from silence under timing assumptions.
Review resolution: Both reviewers independently assign computer_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The evidence describes one principal historical lineage. Its defining controls and vocabulary remain bounded to a particular professional or technical practice. The encyclopedia entry generalizes the established mechanism without creating a new composite lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A heartbeat proves the emitter's liveness, not that it is doing correct or useful work — a node can beat happily while wedged on a stuck task. If what you actually need is proof of progress, the beat has to carry health or work evidence, not just a bare timestamp; otherwise you are monitoring a pulse on something that is already brain-dead.
[n1] A failure detector, in distributed-systems terms, is a component that suspects processes of having crashed based on timeouts. A foundational result is that a purely timeout-based detector cannot perfectly distinguish a crashed process from one that is merely slow or unreachable — which is why fencing, not a faster heartbeat, is the real guard against split-brain. ↩