desk-incident-responselisted

# Incident response An incident is any moment when the exchange record and the desk's expectation disagree, or when the desk cannot see the exchange at all. The order of operations never changes: stop adding, look, contain with approval, review. Improvising is how a small problem becomes a large one. ## Declaring one Any Bot can declare. Post on the floor: ``` INCIDENT INC-20260911-01 | 11:40 UTC | SG-20260911-02 | unknown send result | owner: Execution Trader ``` The Desk Lead confirms the owner — the Execution Trader for anything about orders or positions, the Risk Manager for exposure, the Desk Lead for access and outages. New proposals pause until it is contained. ## A. A send whose result you do not know A timeout, a reset connection, a 5xx, or an exception after the request left the machine. 1. **Do not resend.** 2. Ask the exchange about the exact order you sent: `GET /v2/order --query client_order_id=<id>`. This is why the id is chosen and written down *before* the send — the recovery is a lookup, not a deduction. 3. **Found.** Carry on with reconciliation as normal and journal that the response was lost. 4. **Not found.** Corroborate before believing it: `GET /v2/openOrders`, `GET /v2/history/order` for the symbol and window, `GET /v2/history/fill`, `GET /v2/positions`. A single read from a service that just timed out deserves a second opinion. Once corroborated, the send did not land, and a replacement may go out — with a **fresh** client order id and the us