A trader adds a strategy to a chart, sees “No data” in the Strategy Tester and asks whether the idea failed. That screen does not yet answer the question. It can mean that the selected setup has not produced a completed-trade sample. Before changing an indicator or comparing percentages, make the missing stage visible.
TradingView's own support article lists several possible causes: the script may not be a strategy, it may not issue order commands, its conditions may never occur in the selected history, it may lack the capital required for an order, or it may have a runtime error. These are different failures. One screenshot of an empty report cannot choose between them.
My useful starting point is a small evidence chain. A bar is available. The rule evaluates that bar. An order command is reached. The simulator records an entry. An exit completes a trade. A result belongs at the end of that chain. A debug count or marker belongs beside each earlier stage.
Start with an unchanged copy
Save the script version, symbol, timeframe, selected dates and strategy settings before you troubleshoot. Keep the original entry and exit conditions. Otherwise, a change that makes the report nonempty can quietly become a different strategy, and the trader may compare its number with the original idea.
For example, changing a confirmed-bar condition to an intrabar condition is not just a display fix. It changes when a decision can happen. Removing a filter can create trades, but it does not prove that the filtered rule worked. Treat such changes as separately named experiments, with a reason and an expected effect.
The first check is basic but decisive: confirm that the script is declared as a strategy rather than an indicator. Then locate the existing entry or order command. Plotting a BUY label is not itself an instruction to the Strategy Tester to create a simulated trade.
Instrument the stages without adding orders
The following Pine-style pseudocode describes the diagnostic shape. It is not a drop-in replacement for a strategy and has not been presented as a recorded run. Place observations around the existing path; do not introduce a second order command simply to test the display.
on each bar allowed by the frozen timing rule:
bars_evaluated += 1
record(bar_time, rule_inputs)
if original_entry_condition:
entry_conditions_true += 1
mark the signal bar
if original_order_branch_is_reached:
order_branches_reached += 1
record(entry_id, direction, intended_quantity)
execute the existing order command once
observe the simulator's recorded position and completed trades
These observations separate two questions that often get combined. Did the condition occur? Did the execution path reach the existing order command? A third observation, the simulator's actual position or trade record, is still needed. Reaching a function call is evidence about control flow, not proof that a completed trade exists.
Record the time of the signal separately from the time of the modeled entry. A closed-bar signal and a later fill are not the same event. Use the strategy's actual calculation and order-processing settings when explaining that difference.
Read the smallest table that distinguishes the failures
| Observed stage | Next inspection | What it does not prove |
|---|---|---|
| No evaluated bars in the intended interval | History, dates and the observation gate | That the trading condition is false |
| Bars exist, but no entry condition is true | Inputs and the condition on those exact bars | That another parameter would work later |
| The condition is true, but the order branch is not reached | State guards, existing positions and branch logic | That the broker or simulator rejected an order |
| The existing order branch is reached, but no entry is recorded | Capital, quantity, contract settings and runtime errors | That the strategy has a losing result |
| An entry is recorded, but no exit is complete | Exit rule and the end of the selected interval | That the open position should be closed artificially |
| Completed trades exist | Rules, costs and the exact sample | That historical fills will repeat live |
The table is a proposed diagnostic contract. It does not diagnose an unseen script. It tells the developer and trader what evidence to bring to the next check.
A counterexample: a visible label with no trade
Suppose the script marks a long signal, but its existing-position guard prevents the order branch from running. The chart now contains a convincing BUY label. The Strategy Tester still contains no new trade. Increasing initial capital would not fix that particular path, because the order branch was never reached.
Now change the case: the branch is reached, but the configured order size cannot be afforded under the instrument's settings. The same visible label and empty report can occur for a different reason. Here the capital and quantity checks are relevant. The label alone cannot distinguish the two cases.
This is why I would preserve both the rule marker and the execution-path observation. They answer different questions. A successful diagnosis names the earliest stage that differs from the written expectation.
Three acceptance cases before calling it fixed
Positive case: choose a documented historical bar where the frozen rule should enter. Keep the input values and signal time. Confirm the intended branch is reached once and the simulator records the expected entry. If the exit falls inside the test interval, confirm the completed trade too.
Negative case: choose a bar where a required condition is false. The marker and branch observation must agree that no entry is intended. A repair that creates an entry here has changed the rule rather than only restoring its execution.
Boundary case: put an otherwise valid signal near the end of the available history. State whether the rule can complete an exit within that interval. An open position must not be counted as a completed winner or loser just to make the report look complete.
Each case needs its expected behavior written before the run. A screenshot can then show whether the actual path matched that expectation.
What a completed sample looks like
The frozen Supertrend case provides a concrete reference for a completed sample: 984 completed trades, including 394 take-profit exits, with a measured win rate of 40.04% in this simulation under stated costs. That count belongs to its own rules, EURUSD and EURJPY H1 data, period and cost assumptions. It is not a TradingView diagnosis and is not evidence that another script should produce the same trades.
An empty report cannot be compared with that percentage. First establish what was evaluated and recorded. Then compare only results whose rule and cost contracts are known.
Sources: TradingView's no-orders troubleshooting guide and the canonical Supertrend case, rules and result. This is a diagnostic guide and a historical simulation reference, not a profit forecast or challenge-pass claim.
Top comments (0)