An order heartbeat is a safety stop

A process can lose its network connection while its resting orders remain on the book. An order heartbeat is designed for that failure mode: once accepted, the CLOB expects the process to keep sending valid heartbeats.

It is a safety stop for stale liquidity, not a replacement for order and trade monitoring.

Know what the timer protects

If a valid heartbeat is not received within the required window, the open orders owned by those CLOB credentials are canceled. The cancellation check runs on its own cadence, so the stop is not necessarily instantaneous at the exact timeout second.

Write the heartbeat interval, the credentials it protects, and the expected cancellation behavior in the runbook.

Separate connection health from order state

A WebSocket ping or a healthy process does not prove that every order is live, matched, or canceled. Keep heartbeat logs beside authenticated order updates and trade statuses.

After a timeout or restart, fetch open orders instead of assuming the last local state was complete.

Test the failure path

Use a controlled environment to confirm that the first heartbeat is accepted, subsequent heartbeats are sent on time, and a missed window produces the expected cancellation result.

Record whether an order was already matched before the safety stop. A heartbeat can remove resting liquidity, but it cannot erase a trade that has already entered the lifecycle.

The useful question is not whether a heartbeat message was emitted. It is whether the process, the CLOB, and the account record agree about which orders remain exposed after a failure.

Further reading: Manage orders · Order lifecycle · Real-time order updates.

Explore the markets: Open Polymarket (referral link).