Alerts, Error Handling and Reconnection

In trading systems, errors are not rare events; they are part of daily life. Orders get rejected, connections drop, data arrives late or wrong, fills come in pieces and APIs return unexpected responses. The question is not whether errors happen but whether the system handles them safely. Good error handling follows one principle above all: when in doubt, do not trade. A system that stops and asks for help is far better than one that keeps guessing with real money.

Common error types#

Classifying errors#

The unknown outcome problem#

The most dangerous error is when you do not know whether an order went through, for example after a timeout. Resending could double the position; not resending could miss the trade. The safe approach:

1. Use a unique client order ID for every order.
2. Query the broker for that ID before resending.
3. Resend only if the broker confirms the order does not exist.
4. If the broker is unreachable, stop sending new orders until state is confirmed.

This makes order submission idempotent: sending the same request twice has the same effect as sending it once.

Fail closed, not open#

When a check cannot be completed, the safe default is to block the trade. If the risk check service is down, no orders should pass. If the price feed is stale, no new signals should act. Failing open, letting trades through when checks fail, is how small problems become large losses.

Logging errors well#

Every error log should include the time, component, error type, the order or symbol involved, the system state and what action was taken. This makes later diagnosis possible. See Logging, Audit Trails and Incident Response.

Testing error paths#

Error handling code runs rarely, so bugs hide there. Test it deliberately: disconnect the network, inject bad prices, simulate rejections and partial fills, and kill the process mid order. Confirm the system recovers correctly every time. See Failover, Backups and Disaster Recovery.

Frequently asked questions#

How should a trading bot handle a rejected order?#

Log the rejection reason, alert a human if needed and avoid blindly resending; fix the cause, such as insufficient margin or an invalid price, first.

What does idempotent order submission mean?#

Designing order requests, usually with unique client order IDs, so that sending the same request twice cannot create two orders.

What does fail closed mean?#

When a safety check cannot run, the system blocks trading rather than allowing it, so failures stop activity instead of letting risky orders through.

Next, learn how to prepare for bigger failures in Failover, Backups and Disaster Recovery.