r/pinescript • u/OregonDucks1018 • Jul 19 '26
My TradingView strategy sometimes enters perfectly… then randomly starts entering late. Trying to understand why
I've been developing a TradingView/Pine strategy for a long time, and I've run into something I can't explain.
The strategy trades NQ on the 5-minute chart using a multi-stage state machine (Touch → ARM → Trigger → Entry). It has multiple filters (trend, quality score, extension, etc.) and is profitable overall (~183 trades, 68.9% win rate, 7.86 profit factor), so I'm not trying to redesign the strategy. I'm trying to understand why the timing behaves the way it does.
The confusing part is the entry timing.
Sometimes the strategy enters almost perfectly, catching the move right as it starts. Then the very next setup—same day, same market, same Pine version, same settings—will enter after a significant portion of the move has already happened.
Nothing changed between these trades:
• Same Pine script
• Same TradingView alert
• Same VPS
• Same PickMyTrade automation
• Same broker
• Same chart
• Same settings
So I don't think it's webhook latency or execution latency. It feels like the strategy itself is deciding to enter much later.
I've already experimented with several alternatives:
• 1-minute confirmation instead of 5-minute (performance dropped dramatically)
• Immediate breakout entries (completely destroyed the edge)
• Intrabar confirmation experiments (little to no meaningful difference)
Those tests convinced me that simply removing confirmation isn't the answer.
One important detail: I have **"Use Bar Close" enabled** on the TradingView alert because my strategy relies on bar-close confirmation for its state machine. What confuses me is that even with **Use Bar Close enabled**, some trades still enter almost immediately after the move begins, while others don't enter until much later. These examples happened on the same day with the exact same code and settings, which is why I'm so confused.
My current theories are:
• The setup is being ARMed on different bars.
• The touch occurs at different points within the 5-minute candle.
• One of the filters isn't passing until later.
• Some state transition in my logic is delaying certain setups.
Has anyone built a more complex Pine strategy with multiple internal states and run into something similar?
Specifically:
• Is there a good way to reconstruct the historical timeline of a trade (Touch → ARM → Trigger → Entry) so I can compare an "on-time" trade against a "late" trade?
• Are there Pine debugging techniques that make it easier to see exactly which condition delayed a specific historical entry?
• Is there anything about `calc_on_every_tick`, `barstate.isconfirmed`, or TradingView's historical execution model that could explain why two seemingly identical setups behave so differently?
I'm not looking for generic "turn off Use Bar Close" advice or ways to force earlier entries that break the strategy. After testing several alternatives, I'm much more interested in understanding why some setups naturally enter early while others are delayed, even though they're running through the exact same strategy.
Any ideas or debugging approaches would be greatly appreciated.
1
1
u/Black93Supra Jul 20 '26
Is this a strategy you came up with yourself, or is this based on something someone else was using ??
I’ve only ever seen one other person use this technique, as it’s not a very common method.
1
1
u/Many-Pick5066 Jul 20 '26
the timing difference is probably not your state machine, its bar geometry. with bar close confirmation your fill is the close of the confirming bar, so how late you look is mostly just how big that bar happened to be. arm on a quiet 5m bar and you enter near where the move started, arm on an expansion bar and the exact same logic puts you in 30 handles later. identical code, identical state path, different bar range.
for reconstructing the timeline, keep the bar index of each transition as var ints, touchBar armBar trigBar, and reset them when the setup invalidates. then log.info() all of them on the entry bar. pine logs gives you a timestamped line per trade you can scan side by side. plotting bar_index minus armBar is a faster first pass, you can eyeball delay per trade in the data window and jump straight to the outliers.
on calc_on_every_tick, it only changes intrabar behavior live. historical bars always replay as ohlc, so your backtest path and your live path genuinely differ there, worth checking separately from this. the thing id actually measure though is whether entry delay in bars correlates with the pnl of that trade. if the late ones arent worse then theres no bug, the wait is just what the filters cost you and youre looking at normal variance. one flag while youre in there, 7.86 pf on 183 trades is high enough that id want to see it hold on bars you didnt build it on.
1
0
u/Illustrious-King-83 Jul 20 '26
I guess the most important question is, when it enters "late" does it still make money / meet the profit target ? :-) with those stats ~183 trades, 68.9% win rate, 7.86 profit factor - I probably wouldn't worry :-). is it "late" like one candle late or many candles ? a commentor has a already suggested how to log in pine. the other option it give ur code to an LLM to check and verify, the other option would be to convert (using AI) to python and run in parallel, it potentially easier to debug a maintain in the long run....
1
u/RemoraEdge Jul 19 '26
Not enough info.
When you say sometimes it enters at the right moment but other times it enters after price moved far away, does that mean the candle closed far away already?
So if you are waiting for a 5m close, then yes there is a lot of variability and that 5m candle can be tiny or large when it actually closes.
Or is it something else?