Trading Bot Not Placing Orders or Throwing Errors? Nine Faults and What to Check First
A strategy can be right and a self-run trading bot can still go wrong at runtime: an order that should have gone out does not, a request errors, or the process is alive and the logs keep scrolling, but its state, its request quota or its parameters no longer match the account and the market. The nine faults below are grouped under connection and requests, signals and orders, and data and parameters. Each one gets the symptom and the first thing to check, and where a specific rule is quoted the official documentation is linked.
The nine faults at a glance
| Fault | Does it throw an error? | First thing to check |
|---|---|---|
| Stale state after a disconnect | The disconnect does; the stale state after reconnecting does not | Pull positions and open orders again after reconnecting |
| Order request timeout | Yes | Look the order up by your own client order ID |
| Rate limit | Yes (429, then 418 if you keep sending) | The Retry-After response header |
| Signal never reaches the order program | Not always | The alert log and your receiver's request log |
| Wrong time in force | No | The order's time-in-force setting and where the unfilled part went |
| Different rules on a new exchange | Sometimes (rejected orders) | That exchange's minimum size, precision and order types |
| Mismatched price reference | No | Which price the program uses and how delayed it is |
| Dry-run results that don't carry over | No | The dry run's assumptions on slippage, fills and fees |
| Parameter drift | No | A scheduled review of actual fills |
The rows marked "No" only surface if you go looking; neither the program nor the API will prompt you.
Connection and requests: disconnects, timeouts, rate limits
Disconnects: the orders stay, the program deciding is gone
Orders already resting on the platform do not disappear because your program went offline; if the price gets there they still fill. What a disconnect cuts off is the other half: the program receives no fill reports and can send no new instructions. A stop-loss that lives in local logic, where the program watches the price and then sends a closing order, does not exist while the connection is down. Any protective order that can be placed on the platform should not be left in local logic.
After reconnecting, the positions and open orders in the program's memory are frozen at the moment before the drop. The first thing it should do is pull the real positions and open orders again, and if they don't match, stop and wait for a person instead of guessing its way forward.
An order request times out and you don't know whether it went through
No response is not the same as no order, and resending straight away can leave you with two. Send every order with a client order ID of your own; after a timeout, look that ID up, or look for the order among open orders and trade history, before deciding whether to resend.
Rate limits: the immediate retry after an error is the dangerous part
A request fails, the program retries at once, it fails again, it retries again: a loop like that can use up the whole quota in seconds, and then the cancel request you actually need cannot get out either. When a 429 comes back, stop first. If the response carries a Retry-After header, wait as long as it says; if not, double the wait on each attempt, add some random jitter, and set a ceiling on both the wait and the number of retries.
The limits section of Binance's Spot REST API documentation states that "The limits on the API are based on the IPs, not the API keys", that continuing to send after a 429 leads to an automated IP ban returned as HTTP 418, and that bans run "from 2 minutes to 3 days". Keep headroom for cancel and close requests, so a loop polling market data does not eat the quota they need.
Signals and orders: lost signals, time in force, a new exchange
The alert fired and the order program did nothing
Between a chart alert and an exchange order there are four stages: the alert triggers, the webhook is sent, your receiver gets it, the order program submits. TradingView's Pine Script alerts FAQ says to "Check the logs in the alert manager to see whether an alert occurred"; set that log against your receiver's request log to find the stage where the signal stopped. The same FAQ gives two reasons an alert goes quiet without any fault on your side: "Created alerts do not fire after they expire", and "If more than 15 alerts occur within three minutes, the system automatically halts further alerts."
The wrong time in force
A GTC order leaves its unfilled part resting on the book. An IOC order fills what it can at once and cancels the rest. A FOK order is cancelled whole unless it can fill completely at once. A program that books every order as fully filled will overstate its position with IOC and lose track of the resting remainder with GTC.
Moving to another exchange changes the rules
With an open-source library such as CCXT the method names are shared: its manual says all exchange classes "share a set of common methods". What each exchange supports is still its own. The manual points to a .features property on major exchanges that shows "what methods and functionalities are supported for each market-type", supported time-in-force types included. Minimum order size, price and quantity precision, and rate limits need rechecking for each exchange before the same code runs somewhere new.
Data and parameters: price references, dry runs, parameter drift
The price the program reads is not the number you see
Last traded price, best bid and ask, and index or mark price are three different references, and at the same moment they can show different values. Add data latency and the candle that has not closed yet, and the program's "current price" may not match the chart in front of you. A program working from the wrong reference decides on a skewed basis even when nothing goes wrong at runtime. See The Market an AI Tool Sees Isn't the One You See: Data Sources, Latency and Price References.
Dry-run results that don't carry over to live trading
Freqtrade's dry-run mode is a useful example, because its configuration documentation lists the assumptions: "Orders are simulated, and will not be posted to the exchange"; "Market orders fill based on orderbook volume the moment the order is placed, with a maximum slippage of 5%"; "Limit orders fill once the price reaches the defined level - or time out based on unfilledtimeout settings"; and the wallet is simulated from the dry_run_wallet setting. None of these is guaranteed on a live book, so go through them one by one before switching.
Parameter drift: no errors, it just stops fitting
A grid's bounds and spacing, the period of a trend strategy, the percentage used for a stop-loss: each was tuned on a particular stretch of the market, on the unstated assumption that volatility afterwards would be roughly what it was then. When the market changes state the program throws no error and the API returns as normal. It simply keeps placing orders with parameters that no longer fit.
The only place it shows is the fill history: fill frequency out of line with what you expected when you set the parameters; in a range strategy, price hugging one side while the levels on the other side go unused; a worsening profit-to-loss ratio per trade. Set a fixed review schedule and line the period's actual fills up against the original assumptions.
Three things to put in place before you start
- For every strategy you open, answer "if I disconnect right now, what happens to this order?" If you can't, don't open it yet. The answer usually points to one action: place the protective order on the platform.
- Keep a switch that stops the program within seconds. Once stopped it sends no new orders, and stopping does not depend on editing a config and redeploying.
- Have the program regularly write three numbers somewhere you can see them: current position, number of open orders, and the time of the last successful request. With those you can quickly tell which of the faults above you are dealing with; without them you are left digging through logs.
If the idea behind the strategy or the skeleton of the code came from an AI, check the parameters and thresholds it gave you against the official documentation one by one; the reasons, with four worked examples, are in Why You Can't Just Act on AI Trading Advice. For API key permissions and IP restriction, see How to Set Up a Binance API Key Safely.