AI Trading Bot Signals: 8 Checks for Stale or Incomplete Data

DN AI Trading Series · Signal quality · Checked 6 November 2026 (SAST)

A YouTube demonstration usually shows the exciting part: a signal appears, a bot reacts and a trade follows. The less visible part is the evidence behind that signal. Which market supplied the price? Was the candle still changing? Did the process wait before acting? Did an old alert survive a settings change?

These are practical questions even when the strategy uses AI. Adding a language model to a workflow does not explain a timestamp or recover a missing message. Before evaluating the model’s interpretation, establish what information it actually had.

Give every timestamp a specific meaning

A timestamp becomes useful when its label says what happened. “Updated at 12:01” might describe a market event, a message, a dashboard refresh or the calculation itself. Comparing unlabeled times can produce a precise-looking answer to the wrong question.

TradingView illustrates why the labels matter: its {{time}} alert placeholder describes the bar’s beginning, while {{timenow}} describes the alert’s trigger time, with second-level precision. Substituting one for the other changes the interval you are measuring. [1][2]

Inspect one signal before drawing a conclusion

The inspector starts blank. Choose an individual event or a fixed-duration candle used by a closed-bar strategy. Enter explicit-offset timestamps such as 2026-11-05T12:01:20+02:00 or the equivalent 2026-11-05T10:01:20Z.

For the candle mode, record the finality of the exact payload used to build the signal. A candle that is final when you look later may have been open when the signal was produced. Enter an optional source-item receipt time if your log identifies it.

The two maximum-age fields are your scenario assumptions. Leave a limit blank when it is unknown. Load fictional example supplies the case discussed below, including invented limits of 10 and 5 seconds. They are teaching values, not recommended operating settings.

1. Match the source to the intended market and input

Start with identity before age. Record the venue or data provider, product, exact symbol, quote currency, timeframe and input field. A recent observation from the wrong market does not become appropriate because its timestamp passes a test.

Also distinguish the latest trade, bid, ask, mark price and candle value. Write down which one the strategy expects. If the strategy intentionally uses one market to trade another, retain that relationship as an explicit assumption rather than silently treating the prices as interchangeable.

Chart type can matter as well. TradingView documents that non-standard charts such as Heikin Ashi and Renko can expose synthetic prices rather than the instrument’s actual prices. Its chart-data variables also distinguish a finished bar’s values from the developing values of an open bar. [3]

A useful beginner check is to ask the bot supplier for one redacted signal record and trace its input back to the named source. If the only evidence is a screenshot with a ticker and a green indicator, the input’s identity remains incomplete. The inspector cannot fill that gap.

2. Normalize time zones, units and timestamp resolution

Keep the original timestamp and a normalized UTC version. Do not strip an offset and then assume the remaining clock time is UTC. In the fictional example, 12:01:20 at UTC+02:00 is the same instant as 10:01:20Z, not a two-hour processing delay.

Interface clocks can differ from exported records. TradingView says its alert interface uses the operating system’s time zone, while alert-log CSV exports use UTC. Changing the chart’s time zone does not change how alerts operate. [4]

Check the units before importing an epoch number. Binance Spot’s stream documentation uses milliseconds by default and describes an optional microsecond setting. Its payload documentation separately labels event time and the kline’s start and end fields; they should not be merged into a generic “timestamp.” [5][6]

This inspector accepts explicit-offset date-time strings with up to millisecond precision. It rejects a bare local time or raw epoch value instead of guessing its interpretation. A source that reports whole seconds cannot support a claim that you measured the underlying event to a millisecond merely because the display has three decimal places.

UTC normalization changes how a timestamp is represented; it does not synchronize the devices that produced it. NIST’s time-service guidance notes that client-observed accuracy depends on the network path. Retain the clock-check evidence when comparing records from different systems. [7]

A negative interval is a reason to inspect clock alignment, field meaning and event order. It is not proof that a network delivered information before it existed. The tool preserves these contradictions instead of silently converting them to zero.

3. Check the candle payload’s finality

A candle summarizes an interval. During that interval, its closing price and other developing values may change. A strategy designed to evaluate a completed candle needs evidence about the version it actually used.

Binance Spot’s kline stream includes an explicit x field indicating whether the kline is closed, alongside its time fields. A scheduled ending time in a payload is not a substitute for that field. [6]

Nor does reaching the wall-clock boundary prove that a final payload has arrived. TradingView explains that a bar-close alert can wait for the first trade in the next bar; quiet trading or technical delays can delay it. Its documented no-trade fallback is also a reminder that formal close and alert delivery are separate events. [8]

The inspector therefore asks two different questions: has the entered fixed-duration boundary been reached, and what finality did the used payload report? “Unknown” remains unknown even if the boundary is in the past.

An intrabar strategy may intentionally work with a developing candle. That requires its own documented design and testing. This tool’s candle mode is specifically for a closed-bar strategy, so an open-payload result does not mean that every intrabar strategy is invalid.

4. Measure age at the decision point

A source item can be timely when received and older by the time a decision uses it. Time can pass while work is queued, an indicator is calculated, an AI response is generated or a person reviews the result. The timestamp of the newly created explanation does not reset the timestamp of its evidence.

For an individual event, the inspector measures from the entered event time. For a candle, it measures from the entered candle opening time plus its fixed duration. The latter is labeled time since the scheduled candle boundary; it is not an estimate of the age of the latest underlying trade.

Compare that interval with signal age separately. A two-second-old signal can summarize an older observation. An older signal can also remain within a strategy’s stated validity window. You need both the measured interval and the rule that gives it operational meaning.

Use the actual recorded decision time when reviewing an incident. Replacing it with the time you happen to open the worksheet changes the question. The inspector uses a fixed reference time so an exported case remains reproducible.

If a strategy combines several inputs, inspect each relevant source and preserve their relationships. One recent price cannot establish that a news item, higher-timeframe candle, balance snapshot or other dependency was equally current.

5. Separate a live connection from complete data

A functioning connection is one observation about the transport. It does not establish that every market update required by the strategy is present, in order and correctly applied.

Coinbase Advanced Trade documents a heartbeat channel and a counter for monitoring heartbeat-message continuity. A steady heartbeat counter does not establish that every market update was received and applied. Its WebSocket overview also warns that messages can be dropped or arrive out of order. Interpret each channel’s documented fields in their own scope; do not apply a sequence rule copied from a different service. [9][10]

For an order-book strategy, the relevant question includes whether the local book was initialized and maintained correctly. Coinbase’s Level 2 channel describes snapshot and update messages for that purpose. Receiving a recent update is insufficient if the state it modifies was never correctly established. [11]

Ask the supplier what happens after a disconnect or gap: which state is rebuilt, how missing history is handled and what evidence allows new decisions to resume. “Reconnect automatically” leaves those questions open.

A quiet market adds another distinction. A lack of new trades can be real; it should not automatically be called a broken connection. Conversely, an active heartbeat does not make an old trade recent. The inspector does not diagnose either condition because it does not subscribe to a live feed.

6. Confirm which alert and script version is running

The chart you are looking at may not represent the configuration that created an existing alert. TradingView documents that a running script alert uses a saved copy of the script, its inputs and the chart’s symbol and timeframe. Updating those items on the chart does not update that saved alert; the alert must be recreated to use the changes. [2]

Record the alert identifier, creation time, script version, inputs, chart type, timeframe and trigger condition. After a deliberate change, compare the new record with the old one and reconcile which alerts remain active. Do not assume that a newly edited screen is evidence of a newly deployed signal configuration.

A bar-close trigger addresses one source of changing intrabar conditions. It does not eliminate every form of repainting. TradingView’s alert FAQ discusses higher-timeframe requests and differences between realtime and historical calculations. [12]

There can also be misleading labels across products. The current 3Commas Signal Bot JSON guide says its Timeframe setting affects alert-comment naming and bot-list filtering independently of the TradingView timeframe. A matching label on the bot screen is therefore not sufficient evidence of the source calculation’s interval. [13]

When a historical chart looks better after refresh, preserve the earlier alert record and the input version. A refreshed chart alone cannot reconstruct what was available when the original decision was made.

7. Trace delivery separately from calculation and execution

Follow the same signal through its available records: source input, signal creation, downstream alert delivery, bot processing and any resulting exchange order. These are different stages. Evidence from one stage should not be used as a receipt for another.

TradingView says a webhook can fail to reach its destination and directs users to the Webhook status column in the alert log. Its documented three-second server-processing limit concerns the webhook request; it is not a universal market-data freshness limit or an exchange-fill guarantee. [14]

The optional receipt field in this inspector has a narrower meaning: when the signal-producing process received the exact source item. Do not paste a downstream bot’s alert-receipt timestamp into it. If you need the latter, keep it as a separate event in your own audit record.

If an alert or order outcome is uncertain, checking timestamps does not resolve whether it already produced a trade. Use DN’s order-timeout guide to reconcile the order before considering another submission. A more recent retry timestamp does not identify what happened to the original request.

For a vendor-managed system, you may only have part of the timeline. Mark the unavailable stages explicitly. Do not report an end-to-end latency measurement when you have only two application log entries with uncertain clock alignment.

8. Define what happens when the evidence is missing

A timing check becomes useful when the workflow has an explicit response. Write the limits and required evidence before seeing an inconvenient signal. Specify which source, interval and strategy version the policy covers.

For example, a closed-bar entry policy could require the used payload to be final, a known source reference, reconciled timing and an entered maximum age. These are proposed policy components, not a claim that any particular number makes a strategy safe.

Separate the response for new exposure from management of existing positions. Holding new entries while evidence is unresolved does not by itself cancel existing orders, manage a holding or replace its protective controls. DN’s bot exit checklist addresses those responsibilities when a system is paused or retired.

Record who can change the limits and what evidence permits a restart. Otherwise, a tolerance can become a moving target: each rejected signal prompts another increase until the check no longer constrains anything.

Return to the paper-to-live checks when a change affects the strategy’s operating assumptions. Fixing a timestamp does not validate the strategy around it.

Worked example: a fresh signal with an older candle reference

Assume a fictional closed-bar strategy uses a 60-second candle. The following times are invented to show the arithmetic. They are not measurements of TradingView, 3Commas or an exchange.

The fictional source-reference limit is 10 seconds, so the 20-second interval exceeds it. The separate signal-age limit is 5 seconds, so the two-second signal age is within it. One favorable comparison cannot erase the other.

These logs locate elapsed time between recorded events, but they do not explain its cause. The 16-second receipt-to-signal interval might contain several processing stages. Calling all of it “AI inference latency” would require additional instrumentation.

Change finality to Unknown and the arithmetic still exists, but the record no longer establishes that the used candle was final. Move the source receipt after the signal and a chronology conflict appears. Increase a limit and the comparison changes, while the underlying record remains exactly the same.

There is another boundary to preserve: the latest trade inside this candle could precede its scheduled end. The tool does not know that trade’s time. It cannot convert “20 seconds since the boundary” into “the latest market observation is exactly 20 seconds old.”

Write a short response policy you can actually follow

A practical policy fits beside the signal record. It names the evidence, the comparison and the next action without collapsing different failures into one color.

The same record should make an override visible. Store the original result, who changed the policy and why. Recalculating with a more permissive threshold should not overwrite the evidence that triggered the review.

Methodology: what the inspector calculates

The inspector is a deterministic worksheet. It accepts one source item, one signal creation time, one fixed decision time and an optional source-item receipt time. An event-mode source time means the documented event timestamp. Candle mode uses an opening timestamp, an explicit fixed duration and a reader-recorded finality value.

Explicit offsets are normalized to UTC while the original strings remain in the export. The model uses integer milliseconds for the supported precision. Missing fields remain unknown; an explicit zero maximum age is a real scenario input. Equality with a limit is included in the within-limit comparison.

Each result describes its own dependencies. Invalid or absent inputs prevent the affected calculation; other interpretable intervals remain visible. Signed intervals remain visible. Contradictory event ordering is flagged separately from a scheduled candle boundary that has not yet been reached. A within-limit result remains conditional on the supplied clocks and field meanings.

For candles, the calculated boundary is a schedule. It does not prove when the source finalized, published or delivered the bar. The model does not infer a final flag from elapsed time. It also does not retrieve trades, verify bar alignment, reconstruct missing history or determine whether the strategy chose the correct bar.

The candle model is limited to an explicitly entered fixed-duration interval. It does not construct exchange sessions, daylight-saving schedules, calendar-month bars, tick bars, range bars or Renko bars. The reader must not substitute a guessed fixed duration for one of those structures.

The optional source-item receipt time divides a recorded interval into stages. It does not isolate network latency, queue time or model inference time. Cross-system clock synchronization and source timestamp accuracy are not verified.

JSON and CSV exports preserve the scenario, normalized times, results and source references. Calculations run locally in the page. The inspector does not request credentials, connect to an account, send an alert or place an order. Its output is an audit aid, not a trading instruction or a universal freshness score.

Frequently asked questions

Primary sources

These official sources were reviewed on 6 November 2026 (SAST). Product and channel scope matter. None supplies a universal acceptable delay for every strategy.

1. How to use a variable value in alert — TradingView
2. Alerts — Pine Script v6 concepts
3. Chart information — Pine Script v6
4. What timezone is displayed in alerts? — TradingView
5. General WebSocket Streams information — Binance Spot
6. Spot WebSocket stream payloads — Binance official repository
7. NIST Internet Time Service
8. Delays in OncePerBarClose alerts — TradingView
9. Heartbeats — Coinbase Advanced Trade
10. Advanced Trade WebSocket Overview — Coinbase
11. Level 2 order book — Coinbase Advanced Trade
12. Alerts FAQ — Pine Script v6
13. Signal Bot: Comprehensive JSON Guide — 3Commas
14. How to configure webhook alerts — TradingView
15. My Signal Bot Does Not Work — 3Commas
16. Moving from 3Commas v1 to v2: Feature & Bot Migration Guide