TradingView Strategy Entry One Candle Late: Timing Checks

A TradingView strategy entry on the candle after a signal can be expected behavior. With default calculation and order timing, the strategy evaluates a closed bar, creates a market order, and fills it at the following bar's open. Before changing a setting, identify which of those events your chart marker represents. TradingView explains the default one-candle separation.

For NQ and MNQ traders reviewing an opening-range entry, this guide isolates that timing question. The aim is to establish when information became usable, when an order existed, and when the simulation filled it. A cleaner-looking arrow is not a sufficient reason to change the execution model.

Separate the signal, order creation, and fill

Write three lines for one disputed entry:

• Signal calculation: When did the entry condition become true during a strategy calculation?

• Order creation: When did the script actually create the relevant order?

• Simulated fill: When did the broker emulator execute that order?

A custom signal label may describe the first event. A strategy trade marker describes an execution. The script can also have conditions between the signal and order creation, such as a position-state or session check. Ask the author what each visual means if the source is unavailable.

Keep broker records outside this initial comparison. First explain the simulation on its own terms. If the unresolved discrepancy concerns notification delivery, follow the separate TradingView alert and chart mismatch workflow.

A hypothetical five-minute timeline

Assume standard five-minute candles, a market entry, default bar-close calculation, and default order delay. Use invented index prices and zero modeled slippage solely to make the timing visible.

1. The candle opening at 10:00 finishes at 10:05 with a close of 25,010.00.

2. At that close, the entry condition evaluates true and the strategy creates its buy market order.

3. The next candle opens at 25,011.00. The emulator records the entry on that candle at its opening price.

The signal and fill therefore sit on adjacent candles. This does not imply that the strategy waited another five minutes after recognizing the signal. The prior candle's close and next candle's open are neighboring events. Across a trading break, however, the next available bar can be much later.

Check timestamp meanings carefully. Pine's time identifies a bar's opening timestamp, while time_close identifies its closing timestamp. Calling the example's signal “the 10:00 signal” without explaining the candle label can make a correct 10:05 decision look delayed. TradingView time documentation.

Distinguish calculation settings from fill settings

Bar-close calculation

TradingView's current Script executions control includes an always-active On bar close calculation mode. Other modes add executions: On realtime bar tick evaluates incoming realtime updates, On order fill recalculates after a simulated fill, and On history bar tick adds simulated historical intrabar calculations. Their purpose is to control when the script runs. Script executions reference.

Closing-tick order processing

Documentation checked October 9, 2026 uses both newer and older labels. Your interface may differ, so match the control to its function and Pine parameter rather than relying on a screenshot.

The order-timing control addresses a different question. Current documentation calls it Order execution delay, with One tick and None choices. Broker emulator settings.

TradingView's strategy-properties guide also uses the label Fill orders → On bar close, tied to process_orders_on_close. For market orders created at a close, enabling this behavior allows a simulated fill on that close. Price-dependent orders still require their price conditions. Strategy properties reference.

In the example, closing-tick processing would place the hypothetical fill at 25,010.00 on the signal candle, assuming the same zero-slippage setup. That is a different execution assumption. Record both the setting's section and its value; “On bar close is enabled” alone is ambiguous.

Run a controlled timing audit

1. Preserve a reproducible baseline

Save the exact symbol, timeframe, session, chart type, strategy version, inputs, and execution settings. Record the trade's identifier and entry price, then capture the two neighboring candles. Work in a test copy without live order routing.

Choose several disputed entries before changing anything. Include an ordinary intraday entry and, if relevant, one near a session boundary. This prevents a single convenient example from deciding your conclusion.

2. Locate the first disagreement

For each entry, record the expected signal bar, observed condition bar, order-creation bar, and fill bar. If you can inspect the code, temporarily mark where the condition is true separately from where the entry command executes. If you cannot, request those details from the author.

Watch for a deliberate prior-bar reference. Pine's history operator uses brackets: close[1] refers to the previous bar's close. A condition based on prior values deserves a code-level explanation before you blame the fill model. Pine execution model.

3. Change only closing-tick processing

Hold costs, sizing, signals, and calculation frequency constant. Compare the default-delay baseline with closing-tick processing. For each sampled order, ask whether the condition stayed on the same bar while the fill moved.

If both the condition and entry changed, investigate the strategy's dependencies. An earlier position can affect later eligibility checks. Avoid assuming every changed trade is simply the same trade shifted left.

4. Classify the result

• Condition unchanged; market fill moves: evidence that the processing assumption explains this case.

• Order creation already occurs later: inspect the entry logic and its required information.

• Order exists but remains pending: identify its type and eligibility before expecting a fill.

• Only realtime behavior differs: preserve live observations and review intrabar calculations.

For pending price-based entries, use the NQ and MNQ limit-order fill guide. Changing a market-order timing assumption does not answer a limit-order qualification question.

Avoid fixes that change the question

Enabling calc_on_every_tick adds realtime calculations; it does not give historical bars the same incoming updates. Recalculation after fills serves another purpose again. Treat either change as a separate experiment, particularly when results change after reloading. TradingView calculation properties.

The immediately argument on strategy.close() and strategy.close_all() concerns closing market orders. It is not a general entry-order shortcut. Also, closing-tick processing does not remove the next-tick delay for orders created earlier within a bar. Pine order-processing documentation.

What if the signal still looks late?

Write down what you expected the strategy to know at the earlier moment. Was that expectation based on a completed candle that was still forming then? Did you compare a custom drawing with an actual entry record? If the code is private, send the author the exact symbol, candle times, settings, and one annotated example. A precise question is easier to resolve than a request to move every arrow one candle earlier.

Choose the assumption your workflow can support

A simulated closing-price fill cannot establish that an order sent after confirmation could obtain that price. TradingView specifically warns that alerts generated after a session closes may lead to real orders filling only after trading resumes. Closing-tick processing limitations.

Finish the audit with one sentence per case: “The condition and order were recorded at this close; the fill followed under this setting.” Keep unexplained cases open. Then use the broader backtest versus live testing guide to examine the executable workflow.

Educational content only. Futures trading involves leverage and substantial loss risk. Hypothetical examples and simulated fills do not establish achievable execution or future results.