FIX Heartbeats and Test Requests: Diagnose a Timeout

Measure the right activity

Identify whether the timer concerns incoming messages, outgoing activity or a pending test request. Ordinary FIX messages can demonstrate session activity, so do not require an unsolicited heartbeat at every interval while other traffic flows. Record the negotiated HeartBtInt and the implementation's threshold allowances.

Keep quote freshness and business-response timers separate. A price session can exchange heartbeats while an instrument receives no fresh quote. An order session can remain connected while an order response is delayed. A single green connection icon obscures these distinct conditions and can lead the wrong team to investigate.

Match the test request, not just any response

The FIX standard requires the heartbeat responding to a TestRequest to carry the same TestReqID. Record the sent identifier, local send time, received identifier and receive time. An unrelated heartbeat received after the request does not prove the peer answered that specific test.

Inspect local scheduling delays, receive buffers, process health and network evidence before concluding the remote engine failed. A pause in your own process can make an otherwise timely response appear late. Use a monotonic elapsed-time measure for local timers where available and retain wall-clock timestamps for cross-system investigation. Never calculate one-way network latency by subtracting unsynchronized clocks.

Make recovery a controlled continuation

Follow the configured timeout and logout/disconnection behavior rather than repeatedly opening new sessions. Confirm which process is authorized to reconnect and which sequence state it will reuse. QuickFIX's reconnect, heartbeat and reset settings are examples of controls that must be reviewed as a group.

After reconnection, check session recovery and reconcile any orders whose outcomes crossed the outage. Successful TestRequest handling establishes a narrower result: the session peer responded under the observed conditions. It does not clear pending business exceptions or certify all instruments. Preserve the timeline so the counterparty can compare its own logs.

Example: a responsive peer with stale prices

Assume a fictional session uses a 30-second heartbeat interval and an agreed additional threshold. Last inbound traffic is at 12:00:00. At 12:00:35 the engine sends TestRequest TR-7; a heartbeat containing TR-7 arrives at 12:00:36. That test succeeds. If the last EUR/USD quote remains 11:59:00, a separate market-data freshness check can still fail. The example's times are test inputs, not mandated FIX timeout values.