Heartbeats and Staleness Detection
The simple monitoring pattern of periodic 'I'm alive' signals used to detect when a live trading system, data feed, or strategy process has silently stopped working.
A trading process that has crashed and one that's simply quiet because the market is quiet look identical from the outside unless you build a way to tell them apart. A heartbeat solves this: every live component, a data feed handler, a strategy engine, a risk monitor, periodically emits a small "I'm still running" signal, independent of whether it has anything else to report. A monitoring system watches for these signals and raises an alert the moment one stops arriving, rather than waiting for someone to notice that a strategy hasn't traded in an unusually long time.
Staleness detection is the related check applied to data rather than processes: every incoming price or reference-data update is timestamped, and a monitor flags a feed as stale if too much time passes without a fresh update, a market-hours price feed that goes quiet for two minutes during active trading is almost certainly broken, not simply reflecting an illiquid market. The right staleness threshold depends entirely on context: two minutes of silence is alarming for a liquid large-cap feed during market hours but completely normal overnight or for a thinly-traded instrument.
A common design is layering both checks: the strategy process sends a heartbeat every 10 seconds regardless of market activity, while its input price feed is separately checked for staleness with a threshold tuned to that instrument's typical quote frequency, so a silent process and a silent feed trigger distinct, correctly-labeled alerts instead of one vague "something's wrong" page.
Heartbeats detect a dead process by its silence on a channel that should always be active regardless of market conditions, while staleness detection flags dead or delayed data by comparing its last update time against a threshold tuned to how often that data normally updates, conflating the two produces alerts that are either too noisy or too slow to catch a real outage.
Discussion
💡 Discussion rules
- Ask and answer about this concept. Off-topic gets removed.
- No homework dumps. Show what you tried first.
- Corrections are welcome. Cite a source when you claim an error.
Loading discussion…
Related concepts
- A Monitoring Stack for Live Strategies
- Logging and Structured Events
- Alert Fatigue and Escalation Policy
- Position and Cash Reconciliation Breaks
- System Health Metrics for Trading Systems
- The Trading Incident Response Runbook
- Calibrating Alert Thresholds and False Alarm Rates
- Daily PnL Attribution in Production
Further reading
- Standard site-reliability engineering practice, adapted to trading systems