This scenario might occur using the API function GET /api/v3/order to check an order's status and might return the error "Order does not exist" for an actually
existing order. Due to this error, it is impossible to check the status of a certain order - whether it has been fully or partially filled, or not yet filled.
Official statement says that the time during which the state of the order might be unknown
should not exceed 1 second in a calm market, and 10 seconds during high volatility.
The chart below shows the time (in seconds) how long the error actually lasts (i.e. how many seconds it is impossible to find out what is happening with your order.)
Latencies are measured in milliseconds. Data for the charts is collected from Moon Bot instances run by our users on Tokyo VPS (Vultr or Amazon Japan servers).
All bots are time synced using Japan NTP server jp.pool.ntp.org. If for some reason a bot was not synced, its data is discarded.
Each bot measures latencies on 10-second intervals, calculates max (worst) latency and send this 10-seconds data packet to our server. Then the bot resets its counter and starts measuring again.
The server keeps all such 10-seconds packets from all the bots for 24 hours. Each report is shown on the chart as a dot. Since different instances have started in a different, random time, their intervals expire also differently, thus the data-server has the actual latency data for every moment in time, and the chart looks formed and is updated continuously (despite it consists of single dots).
Trades latency is the delay between the time that the trade has actually been matched by the engine(the "T" parameter in the websocket Trade Stream data) and the time when the trade was received by a client(user) websocket connection.
It is the time in ms the new order takes to be set (in the other words, how long the request to set an order was being processed)
How long all other REST API requests (except settings new order) are being processed.
