Progress Counter Heartbeat¶
Monitor — instantiates Progress-Guarded Livelock Disruption
Has each actor publish a monotonically increasing count of real, committed steps, so genuine progress — not mere busyness — becomes a signal anyone can watch.
A plain heartbeat proves an actor is alive; a progress counter proves it is getting somewhere. Progress Counter Heartbeat has each actor publish a counter that increments only when it completes a real, irreversible step of the shared task — a record committed, a sub-goal closed, a phase advanced — and never when it merely retries, yields, re-sends, or spins. That single binding is what makes it this mechanism and not a liveness ping: a livelocked actor, busy backing off and re-trying forever, shows a flat counter while its CPU is pegged. The counter is the archetype's raw observability layer. It decides nothing and intervenes in nothing; it turns "is the joint task actually moving?" into a number, so that every downstream guard has something honest to watch.
Example¶
A nightly reconciliation job walks millions of records across two services that call each other. Occasionally the pair slips into a retry loop: service A asks B, B is momentarily busy and defers, A backs off and re-asks — indefinitely, at full load, with zero rows reconciled. To the dashboards this looked identical to healthy work: CPU high, requests flowing. The team adds a progress counter — each worker increments records_committed only on a durable write, and publishes it every few seconds. Now the two failure shapes separate cleanly: a crashed worker shows a stopped counter and idle CPU; a livelocked worker shows a flat counter with pegged CPU. During the next incident the on-call sees records_committed frozen at ≈4.2M for about fifteen minutes while load holds at 100%, and knows instantly it is a livelock, not a crash or a slow query. The counter turned an afternoon of guessing into a glance.
How it works¶
The whole craft is in choosing what a tick means. The counted event must map to an irreversible advance of the shared goal, not to activity: a message sent is activity; a message acknowledged-and-applied is progress. Actors expose the counter as a metric, a log line, or a shared field, and any observer compares successive reads — strictly increasing means progressing; flat-while-active is the livelock signature. Per-actor counters can be summed into a joint progress measure, so the same instrument answers both "is anything moving?" and "which actor is stuck?"
Tuning parameters¶
- What counts as a tick — bind the increment to a coarse milestone or a fine-grained step. Finer ticks reveal a stall sooner but risk counting near-activity as progress; coarser ticks are unambiguous but slow to flatten.
- Emission cadence — how often the counter is published. Frequent emission shrinks detection latency but adds overhead and noise.
- Per-actor vs. aggregate — expose each actor's count, a single joint total, or both. Per-actor pinpoints who is stuck; the aggregate answers only whether the whole has stalled.
- Monotonicity strictness — whether the counter may ever roll back (e.g. when a committed step is later reversed). A strictly monotone counter is a clean progress proof; permitting decrements muddies the signal it exists to give.
When it helps, and when it misleads¶
Its strength is that it is the cheapest way to separate a system that is working from one that is thrashing, and it makes the archetype's founding distinction — activity is not progress — concrete and continuously visible. It is the signal every other guard here keys off; without it a watchdog has nothing to time and a barrier nothing to release into.
Its counter is only as honest as the event it counts. The classic misuse is instrumenting the easy event instead of the meaningful one — counting attempts, pings, or bytes moved — so the number keeps climbing while the joint task stays stuck, and a reassuring green line actively hides the livelock it was meant to expose. It also says nothing about why progress stopped or what to do about it: it is a thermometer, not a cure. The discipline is to bind the tick to a genuinely irreversible step of the shared goal, and to confirm that a known stall really does flatten it before anyone trusts it. In formal terms the counter is a liveness probe — "something good eventually happens" — where an is-it-running health check only tests a safety-style "still up."[n1]
How it implements the components¶
Progress Counter Heartbeat realizes the archetype's observability layer — the components that make progress visible, not the ones that judge or act on it:
liveness_observability_signal— the counter is the signal; it makes real progress externally observable, in real time, to anything that cares to read it.activity_progress_separation— by ticking only on committed steps, it draws the busy-versus-advancing line that the whole archetype turns on.
It does not time the signal or act on a flat one — that deadline-and-reset logic is Liveness Watchdog's (joint_state_progress_invariant, recovery_checkpoint_and_reentry_rule) — and it does not identify which states form the cycle, which State-Machine Cycle Detection supplies. It only produces the number they read.
Related¶
- Instantiates: Progress-Guarded Livelock Disruption — Progress Counter Heartbeat is the observability layer every other guard in the appraisal reads.
- Sibling mechanisms: Liveness Watchdog · State-Machine Cycle Detection · Joint-State Cycle Trace · Quiescence Barrier · Randomized Retry Desynchronization · Contention Trace Replay · Bounded Priority Rotation · Circuit Breaker and Cooldown · External Arbitration/Escalation · Leader Election or Token Passing · Exponential Backoff with Jitter
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Progress Counter Heartbeat operates as ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response because it has each actor publish a monotonically increasing count of real, committed steps, so genuine progress — not mere busyness — becomes a signal anyone can watch.
Independent corroboration: The frozen evidence defines Progress Counter Heartbeat as 'Has each actor publish a monotonically increasing count of real, committed steps, so genuine progress — not mere busyness — becomes a signal anyone can watch', so its operative form is Monitoring, Sensing & Alerting.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Monotonic progress counters and heartbeat signals are canonical distributed-systems techniques for detecting stalled but active processes.
Related originating lineages:
- Organizational & Management Science — The organizational_management tradition materially shaped Progress Counter Heartbeat through its own practice of the coordination, governance, learning, and redesign of organized work.
Review resolution: Both blind reviewers agree that computer science is the primary origin. Explicit reconciliation resolves reported ambiguity, domain reach disagreement. Formative alternate lineages are retained as organizational_management; later breadth of use is recorded separately as domain_reach=universal, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Attribution caveat: The exact encyclopedia label appears to synthesize established practices; the primary domain identifies the strongest formative lineage, while the alternates record material ingredients rather than downstream uses. The cross-application to actors and real committed steps is a synthetic generalization of a systems diagnostic.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
A progress counter is necessary but never sufficient: it reveals a livelock and cannot break one. It is the shared infrastructure the rest of the archetype stands on — a watchdog has nothing to time and a cycle detector nothing to confirm without it — yet it is inert on its own. Its trustworthiness rests entirely on one design choice: binding the count to a truly irreversible shared-goal step. Get that wrong and the mechanism flips from detector to camouflage.
[n1] The safety/liveness split in concurrency — a safety property says "nothing bad happens," a liveness property says "something good eventually happens" (the framing is Leslie Lamport's). A progress counter is a liveness probe: a flat counter is a liveness violation, whereas an is-it-up health check only tests a safety-style "still running" condition and stays green straight through a livelock. ↩