forex-scalping.com

TradingView alert on an EMA cross on M5: Once Per Bar against Once Per Bar Close, with a timeline

Picture an alert set to fire when price crosses above the 20 EMA on an M5 chart, with the EMA at 1.0846. Here's one bar.

10:00 the bar opens. At 10:02 price ticks to 1.0847, crossing above the EMA. At 10:04 it falls back to 1.0844. The bar closes at 10:05 at 1.0844, below the EMA.

What each trigger option does with that bar.
Only Once fires at 10:02 and then never again, even on later bars.
Once Per Bar fires at 10:02, the first time the condition becomes true inside the bar, and can fire again on the next bar.
Once Per Bar Close fires at 10:05:00 only if the condition is still true at the close. Here it isn't, so there is no alert at all.
Once Per Minute fires at most once a minute while the condition holds.

The first two gave you an alert for a cross that had gone by the close. The third avoids that, but at a price: it arrives after the bar ends, so you act at the start of the next bar, 1 to 5 minutes after the first touch. On a 6 pip stop, a couple of pips of lag matters. Which cost is lower depends on how often first touch crosses fail to hold into the close.

The timeline makes the difference very concrete. For anyone building alerts that feed an EA or a webhook, Once Per Bar Close is almost always the right choice, because the condition at the close is what the backtest saw. Intrabar alerts can fire on crosses that vanish, and the live results then look worse than the test for reasons that have nothing to do with the strategy.

Backtests usually assume the close version, because most testers act on bar closes. So an alert on the first touch and a backtest of the same rule on closes are two different strategies, and they can diverge a lot. If the live alert is set to Once Per Bar and the backtest used closes, the live system will get entries on crosses that the backtest never took, including every one that reversed before the close. Match the trigger to the test. Where the strategy has been developed on closes, use Once Per Bar Close, accept the delay, and be consistent between the test and the live version.

I learned this the hard way with a webhook to an EA. My backtest used closes on a 20 EMA cross on M5, but I'd set the alert to Once Per Bar because I wanted faster entries. For the first two weeks live results were noticeably worse than the test, and when I went through the trades, a good chunk of the losers were crosses that had flipped back before the candle closed. The backtest had never taken any of them.

Switching to Once Per Bar Close fixed the mismatch almost immediately, though I did lose something on entry. On my trades the delay cost a pip on average compared with the first touch, and on a few fast moves it was closer to three.

What I ended up doing was running the closed bar version for the EA and keeping a separate first touch alert purely as a heads up, so I'm at the screen when the real signal arrives. That way the system matches the test and I'm not tempted to jump in early on my own.

A question for anyone who has tracked it: what share of first touch crosses of the 20 EMA on M5 hold into the bar close on your pair? A count of 50 crosses with a yes or no for whether the close was still on the crossed side gives a rate. If it's 80%, the early alert is mostly right and the lag is the bigger cost. If it's 50%, then half the early alerts are false and waiting is cheaper. I haven't counted it myself, and I'd expect it to vary by pair and by session, so numbers from different markets would be interesting to compare.

If alerts feed a webhook, the trigger type changes how many messages arrive. Once Per Bar can fire many times an hour on a choppy chart, since a cross above and a cross below each count and each bar is a fresh chance. Once Per Bar Close fires at most once per bar, and only when the close agrees. If whatever receives the webhook places orders, a flood of early alerts means duplicate orders unless it checks the position first. Keep the receiving side in mind when choosing: the safest design assumes any alert can arrive twice and ignores the second one.

Use the placeholders in the alert message so every alert records what it saw. TradingView fills in values for close, time and ticker, for example {{ticker}} {{close}} {{time}} in the message box. When an alert fires on a bar close, the close value in the message is the actual bar close. When it fires on a first touch, it's the price at that moment. Saving the messages in a log lets you compare, afterwards, how much the price moved between the alert and the time you acted on it, which is your lag cost measured in your own data.

The close of a one-minute bar is the last tick received before the minute ended. That sounds obvious, but there are a few catches.

If no tick arrives for several seconds at the end of the minute, the close reflects a price from several seconds earlier. In slow markets, a bar's close might be a stale quote.

Different brokers give different ticks, so different closes. A signal based on "close above the moving average" can fire on one platform and not on another, simply because of a tick that arrived 100 ms apart.

There's also the bid problem. The close is a bid price, so a rule that triggers on a close above a level leaves the ask a spread higher. A long entry based on that close pays more than the chart suggests.

For strategies that act on bar close, the signal and the execution happen at slightly different prices. In slow conditions, it's trivial. In fast ones, the next tick can be a pip away.

Using the tick-level event of price crossing, rather than waiting for the close, is the alternative, though it brings more false signals.

A related catch involves the open of the new bar. The first tick of a new minute can arrive late. If the feed stalls for four seconds, the new bar's open is stamped when the first tick finally shows up, and the previous bar's close is whatever the last tick was, possibly well before the minute ended. Chart patterns built from those pairs of numbers contain small artifacts that never existed in the market.

Some platforms let the chart build bars from the ask or from the last price instead of the bid, which changes closes and highs in a way that matters for signal rules. Knowing which price type is feeding the chart avoids a quiet source of mismatch between what a rule saw and what was actually tradable.

Is acting on bar close or on live ticks working better for scalp entries?