Product / Dead Man Monitor
Dead Man Monitor
Detect when an expected heartbeat disappears, while keeping interval, grace and false-positive policy explicit.
Product layer not yet implementedDetect the missing check-in
Dead Man Monitor describes the condition where a process is expected to report within a known interval and the expected evidence does not arrive. The signal is silence, not a direct observation that the process crashed.
How the model should work
- Define the expected reporting interval for a job or service.
- Allow a deliberate grace period for normal execution and network variance.
- Move the monitored item into a missing-heartbeat state when the evidence remains absent.
- Give the surrounding incident workflow enough context to investigate.
These are product semantics for the planned state engine. The current HPH code accepts and stores authenticated requests, but it does not yet calculate Dead Man states, persist per-monitor grace policy or deliver alerts.
Advantages
- turns silence into an explicit operational condition;
- fits scheduled work with a known expected cadence;
- keeps the check-in path outbound and private-network friendly;
- separates missing evidence from a healthy check-in.
Disadvantages and false positives
A missing request can mean a stopped process, unavailable host, expired credential, network failure or a schedule that was misunderstood. A production implementation must distinguish a late signal from a confirmed missing state and must document clock and grace assumptions.
Dead Man versus Heartbeat Monitor
Heartbeat Monitor records and exposes evidence that a check-in happened. Dead Man Monitor evaluates the absence of an expected check-in. They are complementary, not two names for the same feature.
Dead Man versus Dead Hand
Dead Man means no heartbeat. Dead Hand means a heartbeat exists but the progress marker has stopped changing. Dead Hand is a separate product concept and is not available as a state engine in the current build.