After a crypto order times out, treat its execution as unknown. Look up the original order using its client identifier or exchange order ID in the correct account, market and environment. Reconcile its status and cumulative fills before considering another submission. A timeout, missing open-order row or unsuccessful cancellation does not establish that nothing traded.
This article was prepared with AI assistance from a review of KLINEO’s execution code and official exchange documentation. The incident below is a constructed example, not a customer event, live execution test or performance claim.
Ten seconds without an answer
A bot submits a limit buy. The response never arrives. The screen shows an error, the market keeps moving, and the obvious temptation is to press Buy again.
The exchange may already have accepted the first request. Binance documents a ten-second processing timeout and instructs clients to query order status when the result has not appeared in the user data stream. The missing response describes a gap in knowledge about the order. It does not establish an exchange rejection. Binance: General REST API Information.
The immediate operational task is to preserve the original intent and establish what happened to it. Repeating a read can help answer that question. Repeating a trade can change the answer.
Nineteen seconds, one order, two fills
Assume a spot account starts with no BTC and no other BTC activity. An operator intends to buy 0.010 BTC, capped at 60,000 USDT per BTC, using a limit order. These quantities, prices and timings are illustrative. Fees are excluded from the arithmetic.
Before submission, the operator’s record contains the account, environment, symbol, side, quantity and a client order ID: incident-a-entry. That ID stays attached to the original intent throughout recovery.
| Elapsed time | Observed evidence | What the operator can conclude |
|---|---|---|
| 0 seconds | The buy request is sent with the recorded client ID. | An attempt exists; acceptance and fills remain unconfirmed. |
| 10 seconds | The request times out. | The result is unknown. No second entry is authorized by this error. |
| 12 seconds | The first lookup does not return an order. | The original attempt is unresolved. Check lookup scope and continue bounded reconciliation. |
| 15 seconds | The exchange returns the matching order, partly filled for 0.004 BTC. | Some exposure exists; the remaining 0.006 BTC may still execute. |
| 17 seconds | A cancellation is requested for the remaining quantity. | Cancellation is in progress; further fills are still possible. |
| 19 seconds | The terminal record is canceled, with cumulative fills of 0.006 BTC. | The order bought 0.006 BTC in total. The unfilled 0.004 BTC was canceled. |
Two details matter. First, the observation at twelve seconds was incomplete. Second, the cancellation request did not freeze the filled quantity at 0.004 BTC. Another 0.002 BTC filled before the remaining quantity was canceled.
Cancellation and execution can race. Bybit even documents a case where a concurrent cancellation produces two order-stream messages reporting a filled order. Counting messages as separate trades would create a second accounting error. Bybit: Private Order Stream.
The incident’s terminal state is therefore canceled with a fill, rather than canceled with zero exposure.
Keep request, order and fill identities separate
A request identifier helps trace an API interaction. A client order identifier connects a trading intent to an exchange order. An exchange order ID identifies the accepted order. Execution or trade IDs identify its individual fills. Treating all four as interchangeable loses the information needed to recover safely.
On Binance Spot, an order lookup requires the symbol and either origClientOrderId or orderId. The account trade endpoint provides the associated trades, including quantities, prices and commission assets. Binance: Account REST API.
An identity is useful only with its scope. A production spot lookup cannot resolve an order sent to a futures testnet account. A nearby timestamp and similar quantity are weak substitutes for an exact identifier, especially when several bots trade the same symbol. Check KLINEO’s Virtual, testnet and Live distinctions before interpreting an empty result.
Keeping the original client ID also does not create a permanent guarantee against duplicate execution. Binance’s new-order rules permit reuse of the same client order ID once the previous order is filled. A repeat submission can therefore become a new trade under conditions where an operator expects deduplication. Binance: New Order Parameters.
The durable record must remember that an intent already produced an order and account for its fills. The client identifier is the link used to find that evidence.
Read the cumulative quantity before making a new decision
In the example, both fills occur at 60,000 USDT per BTC. The final gross purchase is:
0.006 BTC × 60,000 USDT/BTC = 360 USDT
The original 600 USDT maximum order notional did not all execute. Buying another full 0.010 BTC would bring gross acquired quantity to 0.016 BTC, which is 60% above the original 0.010 BTC intention. The remaining difference to that intention is 0.004 BTC; this arithmetic is not an instruction to place it.
Fees can change the asset actually available for an exit. If a fee is charged in BTC, gross filled BTC and net credited BTC differ. If charged in another asset, that asset must be accounted for separately. Preserve the reported commission asset rather than silently treating every fee as USDT. The exchange trade record supplies these fields. Binance: Account Trade List.
The operator should now hold an incident record with one original intent, one exchange order, its distinct fills, a final cumulative quantity, fees and the observation time. If another process or a manual trade touched the account, reconcile those records too. A balance alone cannot attribute ownership to this order.
Where is the boundary between a retry and a new trade?
The boundary depends on evidence about the original attempt:
| Original attempt | Appropriate next decision | Evidence still needed |
|---|---|---|
| Proven blocked before submission | Correct the admission problem and reassess the intent. | Confirmation that no earlier wire attempt belongs to this intent. |
| Submitted, outcome unknown | Keep the intent unresolved; query its exact identity. | Authoritative order and fill state, or a supported resolution of its absence. |
| Accepted and still open | Manage that existing order according to the operator’s policy. | Any later fills and the result of a cancellation or amendment. |
| Terminal with no fills | Reassess whether a new order remains appropriate. | Current conditions, permissions, balance and risk approval. |
| Terminal with some or all quantity filled | Account for the execution before considering further exposure. | Complete fills, fees, outstanding exits and any other account activity. |
| Conflicting identity or incomplete history | Escalate the unresolved state. | A reliable match between intent, order and executions. |
This is an operator decision aid, not a universal exchange error-code map. A validation rejection before submission and a connection failure after a write attempt require different treatment. When the history cannot prove which occurred, uncertainty remains.
Even a successful acknowledgement needs interpretation. Bybit describes order placement as asynchronous and directs clients to its WebSocket stream for status confirmation. Its history endpoint can lag creation and cancellation. Bybit: Place Order, Bybit: Get Order History.
Use bounded status queries that respect the venue’s rate limits. A tight retry loop can consume the API capacity needed to investigate. Keep the evidence and escalate when a supported lookup path remains inconclusive.
What KLINEO’s recovery code establishes
In the execution implementation reviewed for this article, covered Terminal and agentic workflow paths can return SUBMIT_RESULT_UNKNOWN after an ambiguous submission. A local audit can carry a FAILED status alongside that reason. The local label must be read with its reason code; it does not prove that the exchange rejected or never received the order.
The workflow reconciler looks up the original client identity on the exact exchange connection. If it recovers an exchange order ID, it attempts to attach that ID to the stored workflow and audit records. An identity conflict is routed to manual intervention. Incomplete cumulative fill history stays pending, as can a healthy open order without an authoritative fill.
These are implementation behaviors within covered paths. They do not establish that every order source, venue, outage or historical record can recover automatically. They also do not prove a particular account’s order is reconciled. Inspect its actual records.
For workflow operations, use the activation and recovery guide. A stopped workflow label is not evidence that all exchange orders were canceled or that an account is flat.
Protection has its own order lifecycle
A recovered entry does not establish that its stop or take-profit order is active. Confirm each protective order’s identity, side, quantity, trigger basis, status and relationship to the exposure being managed.
Binance distinguishes a stop that submits a market order from a stop-limit that submits a limit order after triggering. A triggered limit can remain unfilled; triggering alone does not establish an exit. Binance: Spot API Glossary.
For futures, also check the position side and the venue’s reduction semantics. Bybit documents conditional orders that can be canceled for insufficient margin at trigger time. An accepted conditional order therefore does not remove the need to monitor account conditions. Bybit: Conditional Order Behavior.
KLINEO’s reviewed protected-workflow recovery path keeps entry fills, protective legs and any compensating reduction as distinct records. It can remain pending when fills change during protection or when authoritative history is incomplete. An attempted rollback is not proof of zero residual exposure, and a verified reduction is not a promise of no loss.
Keep protection in place while resolving uncertainty. Do not weaken a risk gate or remove a stop simply to make a retry proceed. Review the trading risk disclosure for the broader execution limitations.
Hand over evidence when the state remains unresolved
Use one incident owner to coordinate changes, so a manual action and an automated recovery do not unknowingly overlap. Record the last confirmed state before making an intervention, then verify the exchange result afterward.
For escalation, preserve the exchange and account scope, environment, symbol, client and exchange order IDs, approximate submission time with timezone, error reason, cumulative fills, cancellation result and protective-order status. Distinguish confirmed facts from missing observations. Send a redacted record through KLINEO’s contact page, never API secrets or account passwords.
If KLINEO is unavailable, use the exchange’s official interface to inspect and manage exposure. A suspected credential compromise requires the separate connection-security response; revoking a key does not close existing positions.
Close the incident only when the original intent is linked to a resolved order state, fills and fees are accounted for, remaining exposure is known, and relevant protective or reduction orders have been checked. The useful recovery result is an explained account state. Another green submission message cannot provide it.