TradingView Strategy Alert Timing: Why Fills Differ

A strategy trade appears at 10:00 in TradingView, but the alert log says 10:07. Seven minutes of webhook delay would be a serious problem. It would also be the wrong diagnosis if 10:00 is merely the opening time of the candle containing the trade.

Before changing your automation, identify which event each timestamp describes. A strategy calculation, a simulated fill, a webhook receipt and a broker fill are separate events. This guide follows one trade through those stages so you can investigate the gap that actually exists.

The chart can make an on-time alert look late

TradingView distinguishes realtime execution times from historical trade timestamps. Its support documentation explains that, for historical orders, Strategy Tester can show the opening time of the relevant bar instead of the exact intrabar fill time. Refreshing a chart can therefore change the displayed time without changing the alert that was already sent. See TradingView's explanation of strategy alert and tester timestamp differences.

Consider an illustrative 15-minute candle beginning at 10:00. A simulated limit order fills at 10:07 and triggers an order-fill alert then. After a refresh, the historical trade may be labelled 10:00. Subtracting that label from the alert time invents seven minutes of delay. Preserve the realtime alert record before using a refreshed chart as evidence.

This does not prove that every apparent delay is harmless. It tells you why the alert log is a better starting point than a historical trade label.

Order creation is not an order fill

By default, a strategy calculates at bar close and its newly created market order fills on the next available tick, usually the next bar's open. A condition marker on one candle and a fill marker on the next can therefore be expected behavior. Limit orders have a further distinction: creating the order does not mean its price condition has been met. TradingView documents these rules in its strategy order model.

For AlgoWay automation, choose the event you intend to trade:

Strategy order-fill messages: the trigger follows a fill in TradingView's broker emulator. It is not confirmation that your connected account has filled anything.
Explicit alert() calls: the trigger follows the script's logic and allowed alert frequency. A call placed beside an order-creation command does not become a fill notification.

These are separate event types in TradingView's alert documentation. Use the AlgoWay Pine Script examples for the matching JSON and alert setup. Selecting both event types merely to get an earlier alert can send two instructions for one intended trade.

Three settings that change what you are comparing

Pine strategy setting	Timing effect	What to check
`calc_on_every_tick`	Allows calculation on realtime price updates.	An intrabar condition may disappear by the close. Reloaded history may not reproduce the live sequence.
`calc_on_order_fills`	Adds a calculation after an emulator fill.	Check whether that calculation creates another order. One candle need not mean one event.
`process_orders_on_close`	Allows an order created at bar close to fill on that closing tick in the emulator.	A simulated closing-price fill does not guarantee the same live execution time or price.

Review the actual strategy properties and script settings together. TradingView's strategy properties reference explains the calculation controls. They change strategy behavior; they are not switches for speeding up a webhook connection.

There is also a session boundary to consider. A bar-close alert near market shutdown may reach an execution destination after trading has ended. TradingView explicitly notes this limitation for third-party automation in its strategy documentation. Removing the emulator's one-tick delay cannot keep a real market open.

Trace one event through AlgoWay

Use a demo account to observe a new event with the intended configuration. Start with one symbol and one active alert path. Record the following evidence in a common timezone; keep seconds where available and do not infer subsecond precision from a log that only displays minutes.

Record	What it establishes	Next check
TradingView alert log	Which alert fired, when, and with what message.	Confirm whether it was an order-fill event or an explicit script alert.
AlgoWay Webhook Logs	The received command and the recorded processing result.	Match symbol, action and quantity to the outgoing message. Check errors before assuming a timing problem.
Destination order history or terminal log	Whether the account accepted, rejected or filled the instruction.	Distinguish order acceptance from execution; a pending order can be accepted without filling.

Interpret the evidence in that order:

No corresponding TradingView alert: investigate the saved alert condition and strategy event. An AlgoWay receipt cannot establish an event that TradingView never emitted.
Alert present, no matching AlgoWay entry: check the alert's delivery status, destination URL and selected route. Do not diagnose broker execution yet.
Matching AlgoWay entry, no fill: inspect its processing result and the destination's response. A rejected order and an unfilled pending order require different remedies.
All three records present: compare those timestamps. A gap before receipt and a gap after acceptance are different investigations.

Timestamp differences help locate a problem; they do not, by themselves, measure pure network latency. Logs may mark different processing stages, and clocks or display precision may differ. For a support report, preserve the event times, timezone, symbol, action and relevant error text. Remove account identifiers, webhook URLs and credentials before sharing screenshots publicly.

Change one cause, then observe a new trade

If the alert is using an older configuration, follow the guide to replacing TradingView alerts after settings changes. Editing the chart alone does not update the running alert's saved script and inputs. Historical trades also do not replay as new alerts.

If the event arrives on time but opens or closes the wrong exposure, use the strategy order-action and partial-exit guide. That is a command-semantics problem, not a reason to enable faster recalculation.

Keep the original records when retesting. A useful result is one observed event whose message, receipt and account outcome can all be matched. A refreshed chart may tell a tidier story, but the logs tell you what was actually sent.