TradingView Backtest vs Live Results and How to Test the Difference

TradingView backtests and live results can differ because they use different information, fill assumptions, costs, and execution timing. The useful first question is where the difference starts: the signal, the order, the fill, or the accounting.

A historical strategy report is a simulation. TradingView uses a broker emulator to fill strategy orders from available price data. It does not establish the prices a broker would have given your account. TradingView strategy documentation

For a beginner testing a futures strategy, the practical approach is to document the assumptions, challenge them, and then keep a forward-testing log. That gives you something more useful than two profit totals: a record of what matched, what failed, and what still needs investigation.

Four reasons the results can diverge

Costs were missing or understated

A strategy can generate the same entries and exits while producing a different net result after costs.

TradingView supports percentage, cash-per-contract, and cash-per-order commission settings. Commission applies to entries and exits. Its slippage setting uses ticks and affects market and stop orders. TradingView strategy properties

Check whether your broker's quoted price is per side or round trip, and which exchange, clearing, and other transaction fees it includes. Keep platform and data subscriptions in a separate overhead calculation rather than quietly treating them as zero.

Slippage is a difference between a reference price and the execution price. Define your reference before measuring it. Comparing a broker fill with a signal price measures a different gap from comparing it with the bid or ask when the order reached the market. A single fixed assumption cannot tell you how either gap varies by session or order type.

Historical candles hide the order of events

By default, TradingView infers the path inside historical bars from their open, high, low, and close. It assumes either open–high–low–close or open–low–high–close, depending on which extreme is closer to the open. TradingView broker emulator

This matters when a bar contains both a stop level and a target level. Knowing that both prices occurred does not establish which came first after entry.

Bar Magnifier uses lower-timeframe data to improve historical fill detail. Coverage can be incomplete: TradingView documents a limit of 200,000 lower-timeframe bars, so earlier trades may lack the extra detail. It remains a simulation rather than evidence of your position in an exchange's order queue. TradingView Bar Magnifier explanation

Limit orders need separate scrutiny. The Verify Price For Limit Orders setting can require price to move beyond a limit by a specified number of ticks before a historical fill qualifies. That is a stricter test, not proof that a real order would fill. TradingView strategy properties

The signal changes after the fact

An unfinished bar can change while a strategy is watching it. Some scripts therefore show different historical results after a reload, especially when their real-time calculations rely on intrabar updates. Record signals as they happen before using a later chart to judge them. TradingView repainting explanation

Lookahead bias is another issue: a historical calculation may use information that was unavailable at the decision time. An example is improperly importing a higher-timeframe bar's eventual high. More slippage will not repair that logic. The code needs review. TradingView lookahead-bias explanation

The alert or order workflow differs

With default calculation behavior, a strategy calculates at bar close and its newly created market order fills on the next available tick, usually the following bar's open. Other settings can change that timing. TradingView order timing

A strategy order-fill alert reports an emulator event. It does not confirm a broker fill. TradingView alerts documentation

Check the actual workflow, including manual response time if you place orders yourself. A correct signal can still be acted on late, missed, or submitted with different quantity or order instructions.

A worked example of cost drag

The following is an invented sensitivity test, not AORDS performance or a quotation of broker charges. Assume:

• 80 completed trades, each opening and closing two contracts

• $2,400 total profit before transaction costs

• $2.20 in combined transaction fees per contract per side

• $3.75 adverse slippage per contract per side

• The same trades and quantities in every scenario

There are 80 × 2 contracts × 2 sides = 320 contract-sides.

Fees are 320 × $2.20 = $704. Slippage is 320 × $3.75 = $1,200. The adjusted result is $2,400 − $704 − $1,200 = $496, before fixed overhead and taxes.

Now double only the slippage assumption to $7.50 per contract per side. Slippage becomes $2,400, making the adjusted result $2,400 − $704 − $2,400 = −$704.

The original trade sequence did not change, but the accounting conclusion did. This illustrates why a cost-free result can leave little room for execution friction.

These dollar amounts are deliberately generic. TradingView's slippage input requires ticks, so convert any proposed dollar allowance using the chosen contract's verified tick value. Do not enter $3.75 as though it means 3.75 ticks.

Also avoid subtracting modeled costs twice. If your report already includes them, reconcile its settings before making an external adjustment. This simple example holds the trade sequence fixed; a full rerun may produce different later trades if costs or fills affect strategy logic or available capital.

A practical forward-testing process

Freeze a reproducible baseline

Save the strategy version, inputs, exact symbol, contract month or continuous-series identifier, timeframe, session, timezone, and test dates. Record quantity rules, fees, slippage, calculation settings, and fill settings. Save the trade list and settings together.

Use standard candles for the baseline. TradingView warns that synthetic prices on non-standard charts can produce unrealistic strategy fills. Heikin Ashi has a standard-OHLC fill option, but that does not make every non-standard chart suitable for testing. TradingView non-standard-chart guidance

Change one assumption at a time

Compare the baseline with higher transaction costs, more adverse slippage, and stricter limit-fill requirements where relevant. Inspect trades affected by intrabar ambiguity with additional historical detail where available.

Record which individual trades changed and why. A lower total caused by fees is different from a result that changes because an entry disappears or a stop occurs first.

Observe new signals without rewriting the rules

Choose a review period in advance and record every eligible signal, including ones you cannot execute. Paper trading can help test the workflow without committing trading capital, but label simulated fills clearly.

Keep changes versioned. If you alter a rule halfway through, begin a new test segment instead of merging incompatible observations. Where alerts are used, confirm that their configuration matches the version being tested. TradingView alerts FAQ

Reconcile each session

Compare signal records, alerts, order records, and fills in that order. Investigate discrepancies before changing the strategy to improve the latest result. Keep unresolved cases visible.

A forward-testing log you can copy

Use one record per eligible signal, with linked rows for individual order fills when needed:

• Test version, date, timezone, symbol, and contract

• Signal ID, direction, signal time, and whether the bar was closed

• Intended quantity, order type, entry reference, stop, and target

• Alert time and order-submission time, or “not applicable”

• Order status, rejection reason, unfilled quantity, and partial fills

• Simulated or actual entry and exit times, prices, and quantities

• Fees, reference-price differences, and net result

• Screenshot or record reference, discrepancy category, and explanation

Do not discard a missed signal because there is no completed trade. That omission would conceal a workflow failure.

For review, separate signal mismatches, fill-price differences, fees, and operator deviations. Check the largest adverse execution gaps as well as the average. If a simulated fill has no broker counterpart, investigate it before treating the price difference as slippage.

Frequently asked questions

Does a profitable forward test prove the strategy works?

No. It tests one version over one observed period. It cannot establish behavior across all future conditions, and a short sample can be misleading. A clean workflow and favorable results are separate findings.

Does Bar Magnifier make a backtest equivalent to live trading?

No. Better historical price detail helps investigate fill ordering. It does not recreate your broker's execution conditions or guarantee that your orders would have been filled.

How many forward-test trades are enough?

There is no universal pass number. Specify the questions you need answered, the conditions observed, and unresolved discrepancies. A test that has never encountered a relevant failure mode has not demonstrated that the workflow handles it.

The goal is an explainable comparison. Before drawing conclusions from a TradingView backtest, establish what it modeled and what your forward record actually observed. For information about the project, visit the AORDS homepage.

Educational information only. Futures involve substantial risk. Hypothetical and simulated results do not guarantee future results.