Stop higher-timeframe signals from repainting

The short answer

For a strictly higher timeframe, request the previous completed value inside request.security() and pair it with barmerge.lookahead_on:

confirmedClose = request.security(syminfo.tickerid, "240", close[1], lookahead = barmerge.lookahead_on)

On a 15-minute chart, this uses the previous completed four-hour close, not the developing four-hour close. The offset and lookahead setting work together. This prevents this particular HTF confirmation mismatch; it does not certify your entire strategy as non-repainting or profitable. TradingView explains the confirmed-value pattern.

A closed 15-minute candle is not a closed four-hour candle

Imagine a four-hour session candle spanning 08:00 to 12:00 in the chart's displayed timezone. At 09:15, a 15-minute candle closes, but the four-hour candle still has 2 hours 45 minutes left. Its price can move across your threshold several times before noon.

These hours are an illustration, not universal session boundaries. Use the actual candle boundaries on your symbol. When requesting a timeframe in Pine, "240" means 240 minutes; "4H" is not a valid Pine timeframe string. See Pine timeframe notation.

barstate.isconfirmed outside the request checks the chart bar. Waiting for that close does not confirm a still-open HTF bar. Putting barstate.isconfirmed inside the request is not the fix either: TradingView explicitly says it does not work in that context. See bar-state limitations.

Put the offset inside the requested calculation

For an HTF moving average, offset the completed calculation in the requested timeframe:

confirmedEma = request.security(syminfo.tickerid, "240", ta.ema(close, 20)[1], lookahead = barmerge.lookahead_on)

By contrast, request.security(...)[1] shifts the returned series by one chart bar. On a 15-minute chart, it is not a request for the previous four-hour candle. The calculation inside the request is evaluated in the requested context. See requested contexts and historical/realtime behavior.

These are calculation fragments, not entry instructions or complete NRUNO alert messages. Keep the timeframe strictly above your chart timeframe. A guard for a fixed four-hour request is:

if timeframe.in_seconds() >= timeframe.in_seconds("240")
    runtime.error("Use a chart timeframe below four hours.")

Do not reuse this HTF recipe unchanged for lower-timeframe intrabars. That is a different data-retrieval problem.

What changes when you wait for confirmation?

You trade early information for stable information. During a forming four-hour candle, the confirmed series still represents the preceding completed candle. The next confirmed value becomes available when the new HTF period begins. Your resulting signals can arrive later or disappear entirely compared with developing-bar logic.

The default lookahead_off alone does not freeze an open HTF candle. Conversely, lookahead_on with an unoffset current close can introduce future information into historical results. Do not judge that combination by an attractive backtest. Review TradingView's repainting examples.

Decide which behavior your strategy actually requires. A deliberate intrabar strategy is different from a confirmed-bar strategy; changing one into the other changes the strategy, not just its appearance.

Check the alert before connecting execution

1. Use a normal time-based chart. Record the symbol, chart timeframe, HTF and inputs.
2. Compare the requested value during an open HTF candle and after it closes. Save observations before reloading; a historical chart alone cannot show every intrabar change.
3. Check the rest of your condition. Confirmed HTF data does not stop a current chart-bar price from changing. If your rules require a chart close too, apply that confirmation separately.
4. After editing the script or inputs, recreate the running alert. TradingView keeps a saved copy; an existing alert does not automatically adopt your chart changes.
5. Check the selected alert event and message. Indicator conditions, alert() calls and strategy order-fill events are different sources.

TradingView's alert FAQ explains saved alert copies and repainting-related differences. Our old alert snapshot guide and alert-type comparison cover the setup steps.

A disappearing marker does not undo an executed order

NRUNO routes the instructions your alert sends. A later chart reload is not a cancellation message. Inspect the TradingView alert log, then the NRUNO signal status, then the cTrader position. Keep those three records separate.

If the signal itself changes after a reload, start with Pine confirmation logic. If the expected alert is logged but no position appears, follow the webhook troubleshooting guide. For the actual message and demo connection, use the TradingView webhook setup guide.

Test changes on demo before live use. For setup help, send NRUNO support the symbol, timeframe, event time and redacted message. Do not send your connector secret or full private webhook URL. No signal pattern guarantees execution or profits.