calc_on_every_tick - Jayadev Rana

calc_on_every_tick is a parameter of the Pine Script strategy() function that tells your strategy to recalculate on every incoming price update of a real-time bar, instead of only when the bar closes. Its default value is false — by default a strategy calculates just once per bar, on the bar close. Set calc_on_every_ticktrue and the script runs intra-bar on live data, which is powerful for real-time execution but comes with a major catch: it does nothing on historical bars, so your backtest and your live results can diverge sharply. As of July 2026 this behaviour is identical in Pine Script v5 and v6 — the parameter name, default, and mechanics have not changed. In my 8 years coding Pine Script and shipping over 7,700 strategies for clients in 14+ countries, calc_on_every_tick is one of the most misunderstood flags on the platform. Traders flip it on, watch their forward-tested signals fire beautifully, then wonder why the strategy tester numbers never matched. Let me walk you through exactly what it does and when to actually use it. What calc_on_every_tick actually does By default, a Pine Script strategy behaves like this: it waits for a bar to close, runs your logic once, and then submits any orders. That is why default strategies do not repaint — a closed bar never changes. When you set calc_on_every_ticktrue, the strategy starts behaving like an indicator on real-time bars. Every time a new tick arrives, the whole script re-executes with the current (still-forming) high, low, and close of the bar. This lets you act inside the bar rather than waiting for it to finish. //@version6 strategy("Intra-bar EMA cross", overlaytrue, calc_on_every_ticktrue) fastEma ta.ema(close, 9) slowEma ta.ema(close, 21) longSignal ta.crossover(fastEma, slowEma) shortSignal ta.crossunder(fastEma, slowEma) if longSignal strategy.entry("Long", strategy.long) if shortSignal strategy.entry("Short", strategy.short) With the flag on, this strategy evaluates the crossover on every live tick, so an entry can fire the moment the fast EMA crosses — not 20 or 60 seconds later when the candle closes. The critical catch: historical bars have no ticks Here is the part that trips up almost everyone. calc_on_every_tick does not change anything on historical bars. Historical bars only store confirmed OHLC data — there is no record of the individual ticks that formed them. So on every historical bar, the strategy calculates once, at the bar close, regardless of whether this flag is true or false. That means: On historical data (your backtest): the strategy runs once per bar, on close. On real-time data (live/forward test): the strategy runs on every tick. Because the two contexts execute differently, they frequently produce different order fills. TradingView’s own documentation is blunt about this: strategies using calc_on_every_ticktrue repaint, will not show realistic results on historical bars, and the only way to genuinely test them is on live data. In practice I tell clients: treat the strategy tester report of a tick-based strategy as a rough sketch, never as ground truth. This is a form of repainting driven by the difference between confirmed and forming bars — the same root cause behind lookahead bugs. If you want the fuller picture of how intra-bar behaviour and future-data leakage cause misleading results, I break it down in my guide on request.security lookahead and repainting. calc_on_every_tick: true vs false at a glance Behaviourcalc_on_every_tick false (default)calc_on_every_tick true Historical barsOnce per bar, on closeOnce per bar, on close (unchanged) Real-time barsOnce per bar, on closeOn every incoming tick Repaints?NoYes (real-time only) Backtest matches live?ConsistentOften diverges Alert/entry latencyUp to one full barNear-instant intra-bar When you SHOULD use calc_on_every_tick Despite the caveats, there are legitimate reasons to enable it. Over the years the recurring valid use cases I keep hitting are: Live automation and webhook alerts — you want an order or alert to fire the instant a condition is met inside the bar, e.g. sending a signal to a broker 30 seconds before the candle closes. Scaling in or out mid-bar — pyramiding or partial exits that must react to price during the bar, not after it. Multiple orders per bar — logic that needs to submit more than one order within a single candle. Reacting to real-time indicator states — strategies that mirror how an indicator would update on each tick. If your strategy is a live, automated system pushing orders to a broker, tick-based calculation is usually what you want. If you are purely researching and optimising on historical data, leave it off — false gives you consistent, reproducible backtests. Need a live-safe strategy that behaves the same in backtest and in production? That is exactly the kind of work I do daily. Message me on WhatsApp at +91 77352 68199 and I’ll audit your script. Combining calc_on_every_tick with process_orders_on_close These two parameters are often confused, but they control different things: calc_on_every_tick controls when the strategy logic runs (every tick vs bar close). process_orders_on_close controls when orders are filled relative to when they are created. By default, an order created on the close of a bar is filled at the open of the next bar. With process_orders_on_closetrue, the broker emulator makes an extra attempt to fill that order on the same close it was created on. This is handy for end-of-bar systems where you want the fill to happen at the price your signal was based on, rather than one bar later. //@version6 strategy("Close-based system", overlaytrue, calc_on_every_tickfalse, process_orders_on_closetrue) if ta.crossover(ta.rsi(close, 14), 30) strategy.entry("Long", strategy.long) My rule of thumb from real client builds: Backtest-faithful, bar-close system: calc_on_every_tickfalse and process_orders_on_closetrue — clean, reproducible, no repaint, fills on the signal bar. Live intra-bar automation: calc_on_every_ticktrue so logic reacts on each tick, usually with process_orders_on_closefalse so fills happen at the next available tick, which is closer to how a real broker behaves. A word of caution I give every client: combining calc_on_every_ticktrue with tricks that rely on future data is how you build a strategy that looks flawless in the tester and bleeds money live. I document the most common of these traps in my write-up on the Pine Script bugs that wreck your backtest. Does the version matter? v5 vs v6 No. calc_on_every_tick, its default of false, and its historical-vs-realtime behaviour are the same in Pine Script v5 and v6. If you are targeting queries like “pine script v5 strategy calc_on_every_tick” or “pine script v6 strategy calc_on_every_tick” — the answer is identical for both. The only thing to keep current is your //@version annotation and the broader v6 syntax improvements. I keep a running summary of what changed in the latest Pine Script version for 2026. If you also automate to MetaTrader, the same real-time-vs-historical logic gap applies conceptually when bridging signals — something I handle in my MT4/MT5 automation work. And if you need a custom strategy built the right way from the start, that is the core of my Pine Script development service. FAQ What is the default value of calc_on_every_tick in Pine Script? The default is false. A strategy calculates only once per bar, on the bar’s close, unless you explicitly set calc_on_every_ticktrue. Does calc_on_every_tick work the same in Pine Script v6 as v5? Yes. The parameter, its default, and its behaviour are identical in v5 and v6. Only your //@version line and general syntax differ. Does calc_on_every_tick cause repainting? Yes, on real-time bars. Because it recalculates on every tick using the still-forming bar, live results can change and differ from the historical backtest, which always calculates on bar close. Why are my backtest results different when calc_on_every_tick is on? Because the flag only affects real-time bars. Historical bars contain no tick data, so the backtest still calculates once per bar on close while the live strategy calculates every tick — producing different fills. Should I use calc_on_every_tick with process_orders_on_close? They solve different problems. Use calc_on_every_ticktrue for live intra-bar reaction; use process_orders_on_closetrue to fill orders on the same close they are created on. For faithful backtests, keep calc_on_every_tickfalse. Still unsure which combination fits your system? Send me the script on WhatsApp at +91 77352 68199 and I’ll tell you exactly how to configure it. Risk disclaimer: Trading and algorithmic strategies carry substantial risk of loss. Backtested or forward-tested results do not guarantee future performance. Nothing in this article is financial advice — always test thoroughly and trade with capital you can afford to lose.

calc_on_every_tick in Pine Script Strategies: When to Use It

Search

Rozita Brandson

Signup Newsletter

Latest Posts

Permutation Entropy Regime: Free TradingView Indicator

Astro Cycle Confluence Swing: Free TradingView Indicator

Liquidity Gravity SMC Engine: Free TradingView Indicator

Zerodha Python Automation: Kite Connect Tutorial 2026

Categories

Tag Cloud

Social Media

Jayadev Rana