How to read a Pine error
Before fixing anything, work out which of three kinds of message you are looking at. TradingView's own documentation splits them by prefix [1], and the prefix tells you when the problem happened — which narrows the cause more than the message text does.
| Prefix | Kind | When | How it appears |
|---|---|---|---|
CE | Compilation error | Compile time, before the script runs | Highlighted red in the editor; the script cannot run |
CW | Compiler warning | Before execution | Highlighted orange; the script still compiles, but something is probably not what you meant |
RE | Runtime error | While the script executes, on a particular bar | Red exclamation icon in the status line, with the bar index where it failed |
Two practical consequences of that table.
A CW is not a failure. The script runs. It is telling you the result may not
be what you intended — which is worse than a crash, because nothing stops you
from trading it.
An RE gives you a bar index. That number is the fastest debugging tool Pine
offers: the error did not happen "somewhere in the script", it happened on one
identifiable bar, and whatever is unusual about that bar is your cause.
One caveat, stated by TradingView itself: the documented list is not complete. Their page says new pages for common errors "will likely be added over time", so an error with no code page is normal and not a sign you have found something exotic.
Errors TradingView documents by code
These are the errors with an official page of their own [1]. The message column is the exact string, so you can match what your editor shows.
| Code | Exact message | What it really means |
|---|---|---|
CE10101 | "The condition of the 'X' statement must evaluate to a 'bool' value." | You gave if or switch something that is not a boolean |
CE10117 | "Compiled code contains too many tokens" | The script is too large for the compiler, not wrong |
CW10003 | "The function 'X' should be called on each calculation for consistency. It is recommended to extract the call from this scope." | A function that must run every bar is inside a conditional block |
RE10139 | "Memory limits exceeded." | The script allocated more than the platform allows while running |
RE10143 | "The requested historical offset (X) is beyond the historical buffer's limit (Y)." | You asked for a bar further back than Pine is keeping |
CE10101 is a v6 migration trap, not a typo
This one deserves its own note, because it is the error most likely to appear in a script that used to work. TradingView's page for it states that Pine Script v6 no longer implicitly converts numeric values to booleans, unlike earlier versions [2].
So v5 code that did if someNumber compiles in v5 and fails in v6. The fix is
to say what you mean. Their documentation gives two forms [2]:
newMonth = ta.change(month)
// explicit cast
if bool(newMonth)
label.new(bar_index, high, "New month started")
// or a comparison, which is usually clearer
if newMonth != 0
label.new(bar_index, high, "New month started")
On the cast, TradingView's own wording is worth keeping exactly [2]: a value of
0, 0.0 or na converts to false, and any other nonzero, non-na value
converts to true.
The same trap catches na tests. Checking whether a value is undefined needs
the na() function rather than the value itself [2]:
pivot = ta.pivothigh(10, 10)
if not na(pivot)
label.new(bar_index[10], pivot, "Pivot High")
RE10143 tells you where to look
The two numbers in that message are the offset you asked for and the buffer
limit you exceeded. It is not a bug in your logic — it means a history
reference such as close[500] reached past what Pine retained. The bar index
in the status line is the bar where it first happened.
The limits behind the errors
Three of the five documented codes are not mistakes at all — they are a published limit being reached. The limits live on a different page from the errors [3], which is why the message rarely tells you the number you actually need.
| The error you see | The limit you hit | Published value |
|---|---|---|
CE10117 "too many tokens" | Compiled tokens per script | 100,256 tokens (libraries combined: 1 million) |
RE10143 historical offset beyond buffer | Historical buffer | 5,000 bars for most series; some built-ins up to 10,000 |
RE10139 "Memory limits exceeded." | Collection size | 100,000 elements (50,000 key-value pairs for a map) |
The limits you are most likely to meet next, with their published values [3]:
| Limit | Value |
|---|---|
| Variables in any one scope | 1,000 |
Unique request.* calls | 40 (64 on the Ultimate plan) |
Tuple elements across all request.* calls | 127 combined — the documented workaround is user-defined types instead of tuples |
| Loop execution on a single bar | 500 milliseconds |
| Script execution time | 20 seconds on basic accounts, 40 seconds otherwise |
| Script compilation time | 2 minutes; three consecutive warnings trigger a 1-hour ban |
| Plot counts | 64 |
| Line, box and label IDs | 500 each (polylines: 100) |
| Tables | 9, one per position |
| Bars into the future | 500 |
| Backtest orders | 9,000; Deep Backtesting raises it to 1,000,000 |
| Compilation request size | 5MB |
Two of these explain problems that never produce an error message at all.
The 500-millisecond loop limit is per loop, per bar — not per script. A loop that is fast on recent bars can exceed it on a bar with more history behind it, which is why a script can work for weeks and then fail.
The 40 unique request.* calls limit counts unique calls, not executions.
Requesting the same symbol and timeframe twice is one call; requesting twelve
symbols across four timeframes is forty-eight, and over the limit.
Errors from the AlfaTactix generator
These come from our exporter, not from Pine, and most people never see one — the builder constrains what can be selected, so an unsupported combination is usually not reachable in the first place. When one does fire it is shown in the generate panel, and it means the strategy asked for something the export cannot express. The fix is in the builder, never in the generated file.
| Error | What it means | Where to fix it |
|---|---|---|
UNSUPPORTED_FEATURE | The strategy uses something Basic export cannot emit | Change the strategy in the builder |
| Empty or partial export | A required field in an earlier step was never filled | Re-open the step the builder flags |
Basic export cannot emit multi-timeframe logic, VWAP-based targets, or news filters. If your strategy needs one of those, the export will refuse rather than emit something that behaves differently from what you designed — which is the failure mode that matters, because a silently different script backtests fine and then does not match live.
Do not hand-edit the exported file to get around this. The generated script is the thing the builder can reproduce; once edited, the next export overwrites your change and the version you tested no longer exists anywhere. Change the strategy, export again.
One error that is not ours, and gets reported to us regularly: MetaTrader's
10016. That is an MT5 stop-level rejection and has nothing to do with Pine or
TradingView. It belongs to the MQL5 side — see
Common MQL5 EA errors.
A fix path that works
In order, cheapest first.
1. Read the prefix, not the sentence. CE means it never ran, CW means it
ran and may be wrong, RE means it ran and stopped on a specific bar [1]. This
takes two seconds and eliminates most of the search space.
2. If it is an RE, go to the bar it names. The status line gives the bar
index. Look at what is unusual about that bar — a gap, a session boundary, the
first bar of the dataset, a bar with no volume. The cause is almost always
visible there.
3. Check the declaration before the logic. A script that compiles but shows
nothing in the Strategy Tester is usually an indicator() where a
strategy() was needed. The two are different script types with different
capabilities [4], and no amount of reading the entry logic will reveal it.
4. Check the version line. //@version=6 behaves differently from v5 in
ways that produce errors in previously working code — CE10101 above is the
clearest example. Mixing a v5 snippet into a v6 script is the most common
source of "it worked yesterday".
5. Then use the official debugging techniques [5] rather than guessing: plotting intermediate values is faster than reasoning about them.
6. If you exported it, re-export instead of repairing. A generated file that has been hand-edited is no longer reproducible, and you will debug the edit rather than the strategy.
What not to do
Do not start by rewriting the section that looks suspicious. Pine's errors are unusually specific — a prefix, often a bar index, sometimes two numbers naming the limit you crossed. Every one of those is information that reading the code cannot give you, and discarding it in favour of intuition is what turns a two-minute fix into an afternoon.
Tactix AI on this workflow
AlfaTactix includes Tactix AI: use Tactix Studio to describe your idea in plain language and draft timeframes, signals, filters, and risk into the same six-step Strategy Builder form — or open Tactix Guide on any step when you only need a field explained. Review every value, then export MQL5 or Pine Script from Code Generator (form-first — not untested prompt-to-code).