Trading bot monitoring: stop rules, open orders and restarts

Monitor a trading bot by checking data freshness, exchange state, order progress and account risk. Write the stop and restart rules before launch. A running process and a green profit number do not establish that the bot knows its actual position or can exit it.

The most useful question is concrete: if the next request fails, what remains open at the exchange, who is notified and what may the bot do next? Answer it for a timeout, a missing data update and a restart. Those cases require different responses from an ordinary losing trade.

Watch four different kinds of health

First, observe the process heartbeat: when did the program last report that it was running? Second, observe market data: when was the latest usable price or candle received? A healthy process can keep making decisions from a frozen feed.

Third, reconcile account state. Compare intended and actual positions, outstanding orders, filled quantities and available balances. Fourth, inspect the order lifecycle: a submitted order is not necessarily accepted, and an accepted order is not necessarily filled.

Record both event time and observation time in one time standard. A current dashboard refresh can display an old event. Show unknown state explicitly instead of replacing missing data with the last favorable value.

Write rules that name an action

“Stop after a bad day” is ambiguous. Define the reference equity, valuation currency, reset time, included costs and exact trigger. Then state whether the action blocks entries, requests cancellations or submits exits. Record which actions require manual approval and what happens if one request fails.

Technical rules need the same precision. Examples include refusing new entries when prices are stale, exposure exceeds a limit or order status is unknown. Numeric thresholds should come from the strategy's timing and risk specification; copying another trader's percentage does not validate them.

Keep an independent way to detect a stalled bot. If the program responsible for monitoring itself has crashed, its own alarm code cannot notify anyone. Confirm that the chosen notification path reaches the person responsible for reviewing the incident.

A worked pause and reconciliation example

Assume a hypothetical account begins the monitoring day at 10,000 USDT with a review threshold of a 2% equity decline. The threshold value is 9,800 USDT. If current equity is 9,750, the observed decline is 250 / 10,000 = 2.5%, so the specified review condition has triggered.

Suppose the rule only blocks new entries. The account still holds 0.01 BTC and has an unfilled buy order for 0.005 BTC at 60,000 USDT. That outstanding purchase represents another 300 USDT of potential position value. Pausing the bot does not, by itself, cancel it or sell the 0.01 BTC.

If a cancellation request times out, order state is unknown until verified. The order may still fill. Do not release its reserved risk capacity merely because a local timer expired. Binance's REST API documentation explicitly distinguishes some errors from a known failed execution.

Separate entry halt, cancellation and exit

An entry halt prevents new entry decisions. Cancellation targets unfilled orders already at the exchange. Position exit places an order intended to reduce existing exposure. These are three distinct operations with different failure modes.

Cancellation can race with a fill. A market exit can execute at an unfavorable price; a limit exit can remain unfilled. Protective orders need their own verified status. Do not cancel a protective order merely because an incomplete local snapshot suggests its position has disappeared.

Review order history and current state together after an incident. In particular, a partially filled entry may leave both a position and a remaining buy order. A single label such as “stopped” cannot describe both safely. Document the residual exposure explicitly.

A checklist for restarting after an incident

Before enabling entries again:

• Save the trigger time, strategy version and last confirmed event.
• Refresh exchange positions, balances, fills and open orders.
• Resolve every unknown submission and cancellation status.
• Check that any required protective orders remain valid.
• Confirm data freshness, permissions and available risk capacity.
• Record the restart decision and the person or rule authorizing it.

Test these steps in an appropriate simulation or test environment. Reproduce a restart between submission and acknowledgement, a partial fill during downtime and an alert that never reaches its recipient. Compare the intended and observed states rather than accepting a generic “recovered” message.

Clerix's workflow overview illustrates strategy preparation and analysis. Its testing engines and live execution remain in development; the website does not establish an operating exchange kill switch. Use the bot selection guide to ask a provider which controls are actually available and test their behavior before use.

Frequently asked questions

Does Stop always close everything?

No. Entry halt, cancellation and position exit are separate operations. Outstanding exchange orders are not automatically cancelled, and positions are not forcibly sold merely because new entries stop.

How often should I check the dashboard?

There is no universal interval. Use the strategy's reaction requirements and verified automated alerts to define an observation schedule. Manual checking alone cannot guarantee detection between visits.

Should a bot restart automatically after a loss limit?

Only if the specification explicitly defines the conditions. A timer resetting does not resolve an unknown position or explain the incident. Reconcile state and meet the written restart criteria first.