Why your Pine Script backtest won't match live trading

TradingView's Strategy Tester is a simulation. If the simulation is optimistic, live trading corrects it — painfully. Four things cause the divergence.

1. Repainting

If your logic reads the current, unclosed bar, the backtest sees a candle's final shape while live you only have a forming candle that can still change. The tester “knew” the close; you don't. Fix: act only on confirmed bars. Full detail in Pine repainting explained.

longCond = ta.crossover(close, ta.sma(close, 20))
if longCond and barstate.isconfirmed
    strategy.entry("L", strategy.long)

2. Lookahead via request.security()

Pulling higher-timeframe data with lookahead enabled leaks future values into past bars. The backtest uses information that did not exist yet. Always request HTF series with lookahead_off and offset the series by one bar.

3. Unrealistic fills

By default the tester can fill at the bar's close or an ideal price. Live, you get the next available price with a spread. Add process_orders_on_close=true where appropriate and stop assuming limit orders always fill at your exact level.

4. Ignored costs

Commission and slippage quietly erase thin edges, especially on high-frequency systems. Model them:

strategy("My System",
     commission_type=strategy.commission.cash_per_contract,
     commission_value=0.62,
     slippage=2)

The honest workflow

Confirmed-bar logic, lookahead-off HTF, realistic fills and costs — then validate out-of-sample and run a Monte Carlo so you see a distribution, not one lucky path. That last step is the difference between a tester screenshot and a number you can trust. See how to know if a backtest is overfit and our methodology.

Every Puravida Edge strategy is validated this way — realistic fills, costs, and 1,500-path resampling — not a clean Strategy Tester curve.

How do you test an algorithm's performance on historical data before going live?

In three stages, and skipping any one of them is what produces backtests that fall apart live. In-sample development, out-of-sample validation on data the strategy has never seen, then forward testing in real time before capital is committed.

The in-sample stage is where parameters get chosen and where overfitting enters. Whatever you optimize here will look good here by construction, which is why the result carries no information on its own.

The out-of-sample stage is the actual test. Hold back a portion of history the strategy has never touched — a later period rather than a random subset, so the test reflects conditions arriving after the ones you developed on. If performance collapses, you fitted noise. If it degrades moderately, that is normal and expected.

The forward stage runs the strategy live on data as it arrives, without capital or at minimum size. This catches the failures historical testing structurally cannot: fills that do not match assumptions, signals that fire at times you cannot trade, latency, and data differences between your test feed and your live feed.

Two things must be inside the test rather than adjusted after. Costs — roughly $1.00-1.20 round-turn per micro futures contract on Tradovate or Rithmic, plus around a tick of slippage in normal conditions — and every rule of the account you intend to trade. A strategy validated without the daily loss limit or consistency requirement has been validated for an account that does not exist.

What is the best way to simulate live market conditions in algorithmic trading?

Model the three things backtests get wrong by default: fills, timing, and cost. Each one flatters the result in the same direction, so their combined effect is systematic rather than random.

Fills. Most backtests assume execution at the signal price. Live, you get the price available when the order reaches the book. Model at least one tick of slippage per side in normal conditions on liquid micro futures, and considerably more around news releases and rollover weeks, where fill variance rises for roughly eight days before expiry. On thinner contracts such as micro crude, two to five ticks in volatile conditions is realistic, which usually argues for limit orders or avoidance during an evaluation.

Timing. Bar-based backtests can evaluate conditions using information from the bar they enter on. This produces excellent results that cannot be reproduced. Every condition must be computable from data closed before the entry decision.

Cost. Round-turn commissions on micro futures run roughly $1.00-1.20 per contract on Tradovate or Rithmic, and mini contracts run roughly $3.10-3.98. Across a hundred-trade evaluation with several contracts per trade, that consumes a substantial share of a $3,000 target on a 50K account.

The most realistic simulation available is forward testing on live data without capital, which reproduces all three automatically. It is slow, which is precisely why it gets skipped.

What is the average P&L for an algorithmic strategy after backtesting, deployment and live testing?

There is no meaningful average, and any figure presented as one is describing a selected sample. Published strategy results are drawn from strategies that survived long enough to be published, which excludes the majority that were abandoned. Averaging survivors describes survivorship, not strategies.

What can be described is the shape of the degradation. A strategy typically performs best in-sample, worse out-of-sample, and worse again live, with each step introducing a specific cost. In-sample to out-of-sample loses whatever was fitted to noise. Out-of-sample to live loses execution differences: fills, latency, skipped signals, and costs that were understated or omitted.

Degradation of this kind is normal and does not indicate a broken strategy. What indicates a problem is collapse — a strategy that is profitable in-sample and unprofitable out-of-sample was almost certainly fitted rather than discovered, and no amount of live tuning recovers that.

The number worth tracking is not average P&L but the ratio between your live results and your out-of-sample expectation. Consistently at or near expectation means the model is sound. Consistently far below it means the gap is in execution, which is measurable and fixable, rather than in the edge.

One access note: if the strategy is an invite-only script, settings travel with the invite — how invite-only scripts work covers what you can and can’t change.

FAQ

Why is my TradingView backtest so much better than live results?

Usually one of four causes: repainting (acting on unclosed bars), lookahead in request.security(), unrealistic order fills, or ignored commission and slippage. Fix all four and the gap shrinks dramatically.

Does adding commission and slippage really matter?

Yes — on higher-frequency strategies, realistic costs can turn a profitable-looking backtest into a losing one. Always model them in the strategy() call.

How do I make my Pine backtest realistic?

Act only on confirmed bars, request higher-timeframe data with lookahead off, add commission and slippage, use process_orders_on_close where appropriate, then test out-of-sample and with Monte Carlo.