SHARKRULE / Learn

Stale trading bot data: check the event, receipt and decision times

A price received now can describe an older market event. Before interpreting a trading bot’s signal, check what the value measures, when the event happened, when the tool received it and when the rule evaluated it. An old observation can establish a past condition; it cannot by itself establish the current market state. Missing required data is unknown, not a price of zero or proof that a condition is false.

SharkRule · Reviewed

Separate the market event from receipt and evaluation

Event time describes a source event. Receipt time is when the consuming tool records its arrival. Evaluation time is when the rule uses it. With comparable synchronized clocks, receipt minus event time gives apparent arrival lag; evaluation minus receipt gives local waiting time; evaluation minus event time gives the event’s age at the decision. Arrival lag can include source processing, delivery and clock error: it is not a measurement of network delay alone.

Check the field’s definition before subtracting timestamps. Binance’s Spot trade stream distinguishes event time E from trade time T; its candle stream uses k.T for the candle’s close time. Those are different meanings. The tool must record its own receipt time. If a source does not supply the timestamp you need, keep that part of the diagnosis unknown. A fresh receipt stamp alone cannot date the underlying observation.

A last-trade price, current bid/ask and completed candle close answer different questions. A recent candle close still summarizes an interval; it is not a promise that someone will trade at that price now. Compare the same exchange, Spot pair and price field before deciding that two screens disagree.

Worked timeline: newly received does not mean newly observed

Every price and time below is hypothetical. For an unnamed Spot market, suppose a rule asks whether an observed price is at or below 100. This teaching example accepts only observations whose event age is at most five seconds at evaluation, with synchronized clocks. Five seconds is an invented example boundary, not a recommended setting, an exchange requirement or a SharkRule control. No order is submitted in this exercise.

For the first row, apparent arrival lag is 4 seconds and local waiting is 5 seconds, so total age is 4 + 5 = 9 seconds. Although 99 is below 100, that observation fails the example’s freshness requirement. It does not establish that the condition is true now.

Hypothetical observation ledger; all times UTC, prices in quote-currency units
Event timeReceivedEvaluatedPriceEvent ageInterpretation
12:00:0012:00:0412:00:09999 secondsToo old for this example; current condition unknown
12:00:1012:00:1112:00:121012 secondsFresh enough for this example; 101 ≤ 100 is false
12:00:0312:00:1312:00:139810 secondsLate older event; not a newer current-price observation

Recovered data allows a new check, not a delayed instruction to trade

In the second row, arrival lag is 1 second and local waiting is 1 second: event age is 2 seconds. The example can evaluate the condition again, and it is false. Restoring usable data does not mean acting on the old value of 99. In the third row, a message arrives most recently but describes an event seven seconds earlier than the second row’s event. Keep it as history; do not silently replace the newer observation with it.

Treat input validity and the price comparison as separate checks. The possible results here are insufficient evidence, usable evidence with a false condition, or usable evidence with a true condition. Even the last result would still need the rule’s permissions, limits and other requirements. The timeline demonstrates reasoning about observations, not SharkRule’s internal polling or recovery algorithm.

A missing candle and an unfinished candle need different checks

A recently updated candle can still be unfinished. Conversely, a closed candle can arrive late. Binance’s candle stream reports closure separately with k.x; its REST candle records are identified by opening time. Match the intended interval and boundaries before counting records. If a calculation needs three consecutive one-minute candles and your record contains starts at 12:00, 12:01 and 12:03, three rows do not supply three consecutive minutes: 12:02 is absent.

A gap can reflect a collection failure, an incomplete response or the venue’s documented treatment of intervals without trades. For example, Upbit explicitly does not generate a minute candle when no trade occurs in that interval. That is an Upbit rule, not a claim about Binance or a SharkRule connection to Upbit. Verify the source’s convention before classifying a gap as an outage.

Keep an unexplained gap visible. Substituting zero invents a price; copying the previous close invents an observation. Both can change a rule’s calculation. Recover the required records from the same market and interval where possible, and record whether they were genuinely observed or reconstructed. A chart that looks continuous does not prove its input series is complete.

A checklist for a rule waiting on market data

Use this checklist to build a short diagnostic note. Not every tool exposes every timestamp or setting; write unknown when evidence is unavailable. Do not increase a budget or relax a price condition merely to make a waiting rule act.

  1. Identify the exchange, Spot pair, rule version and required input: last trade, bid/ask, candle close or indicator. Keep the data source consistent.
  2. Record the source timestamp’s meaning, units and timezone, plus receipt and evaluation times where available. Milliseconds and seconds are not interchangeable. Check clock alignment before interpreting a negative or unexpectedly large age.
  3. Inspect the connection and latest usable market update separately. A connection message or successful request does not prove a recent price observation. A quiet market can have no new trades while its connection remains healthy.
  4. For candles, check interval boundaries, closure, duplicates and gaps across the full window required by the rule. A fresh last row does not repair a missing earlier input.
  5. Record the actual waiting reason and the last valid observation. Recheck with current complete data under the saved rule and unchanged limits; do not replay every apparent opportunity during the interruption.
  6. If a real order was already sent, inspect that original order and its fills separately. Data recovery does not settle an unknown submission result, cancel an open order or authorize a replacement.

Common mistakes: treating connection health as price freshness

Binance documents its API as asynchronous, with possible differences in update delay between data sources. A successful response is therefore not a freshness certificate. Nor does an old last-trade time prove a broken feed: first distinguish a quiet market from missed updates using the source’s documented behavior. There is no universal age limit suitable for every input and rule.

Repeatedly retrying requests can make diagnosis harder. Follow the exchange’s request limits and retry instructions; a data retry must not become a duplicate order. Binance warns that an order timeout can leave execution status unknown. Reconcile that order rather than interpreting a working price feed as proof of failure. An unresolved Binance submission must remain a block on further Binance submissions in SharkRule.

Usable data cannot reserve an execution price. Fees, slippage, partial fills, non-fills and exchange outages still matter, and holdings can lose value while a rule waits. Simulation cannot prove future live fills. This guide explains mechanics, not an asset, allocation, position size or strategy to adopt. SharkRule is independent software, not a financial or investment adviser, and is not affiliated with or endorsed by the exchanges.

Next step: compare a waiting explanation with its data timestamp

Open the localized SharkRule simulator walkthrough linked in Sources. It explains reviewing the data timestamp and waiting for fresh data when required inputs are unavailable. Use that explanation to review the condition, activity and available data timestamp of one supported Shark, along with its virtual budget, before deciding whether to start a simulation. The walkthrough does not establish a user-configurable five-second freshness limit or promise a recovery time.

Simulation uses virtual funds and does not authorize real exchange orders. Any later real-money setup requires its own review and explicit start, with availability determined by the current dashboard, account and location.

Frequently asked questions

The page refreshed just now. Is its price current?

Not necessarily. Page refresh, message receipt and the underlying market event have different times. Inspect the source timestamp and its meaning. A cached value can be delivered in a newly refreshed page.

Is missing data the same as a false condition?

No. A false condition needs usable evidence for that comparison. If the required input is missing or too old under the rule’s stated policy, its current truth cannot be established from that input. Record the reason for waiting separately.

Does a missing minute candle always mean a connection failed?

No. Check the market, requested range and source convention. Some venues omit no-trade intervals; others may represent them differently. Do not import one venue’s convention into another or silently fabricate a missing candle.

Does fresh data guarantee an order will fill?

No. Input validity, permission to act and exchange execution are separate. Fresh information can still be followed by price movement, fees, partial fills or no fill, and it does not resolve the outcome of a previously submitted order.

Official documentation and references

Prepared with AI assistance from the linked official documentation. Examples are hypothetical; no live account tests or return comparisons were performed.