Open the Pine Editor at the bottom of a TradingView chart, and the blank script already contains three of the four things any indicator needs. Add a calculation and a plot and you have something on the chart. The interesting part starts afterwards, when the script behaves differently on the live candle than it did on history.
The four parts of a minimal script
- A version comment on the first line, which tells the compiler which language version to use. Copying an old script from a forum without checking this line is the most common reason a script refuses to compile.
- A declaration statement, either an indicator or a strategy. Indicators draw and alert; strategies simulate orders and produce a performance report. Whether it draws on the price panel or in a separate pane below is an argument on this line.
- Inputs, created with the input functions, which turn hard-coded numbers into settings a user can change from the format dialog. A length written as 20 inside the calculation is a script only you can use.
- Calculation and output. Built-in functions cover the standard technical analysis library, and a plot call draws the resulting series.
A moving average indicator is a length input, one call to the simple moving average function against the close, and one plot. That script is complete and useful, and it is the right first thing to build. Add the second average, plot it in a different colour, and you have a crossover you can attach an alert to.
The execution model, which explains everything else
Pine does not run once over a dataset. It runs once for every bar on the chart, left to right, and on each pass the built-in variables refer to that bar: close is that bar's close, high is that bar's high. Historical references use a bracket offset, so the previous bar's close is close with an offset of one. Variables keep their value from bar to bar only if you declare them to persist.
On the rightmost bar the script re-executes on every tick, because the values are still moving. That is the difference between history and live, and it produces the effect where an arrow appears mid-candle and vanishes before the close. The fix is to gate signals on the bar being confirmed, or to compare against the previous bar's completed values rather than the developing one.
The same trap sits inside higher-timeframe requests. Asking a daily series while running on a five-minute chart is legitimate; asking for it in a way that lets the completed daily value appear on intraday bars that came before it is not. A backtest built on that mistake looks superb and cannot be traded, which is the mechanism behind indicator repainting.
Any script that looks flawless on historical bars deserves suspicion before it deserves capital. Check it forward on a demo environment across live sessions, and treat backtest output as a hypothesis rather than a result. Trading on a self-written signal is high risk and the code carries no guarantee of anything.
Alerts: how a script reaches the outside world
Pine runs on TradingView's servers with no network access, no file access and no ability to place an order. The single exit route is the alert system. A script can define an alert condition that the user attaches an alert to, or call the alert function directly at the moment its logic decides something happened, passing a message it composes itself.
Composing the message inside the script is what makes a signal usable. A string built from the symbol, the direction, the entry level and the stop distance arrives on a phone as a complete instruction rather than as "condition met". Set that message as JSON and it can be parsed by a receiving service, which is the pattern described in TradingView webhooks. The delivery settings and the trigger frequency that decide when your alert fires are covered in the alerts guide, and they matter as much as the code.
If you convert the indicator into a strategy, read the properties tab before believing the report. Default settings often assume an order size, no commission and no slippage, and a method that trades frequently turns profitable into unprofitable the moment realistic costs go in. Set the commission and slippage fields to match the account you would actually trade, then look at the equity curve again.
Limits worth knowing before you design
Scripts are bounded on purpose. There are caps on how many series a script may plot, on how many drawing objects it may keep on the chart, on how many separate symbols it may request, and on total execution time. Loops over large historical ranges hit the time limit and the script stops with an error rather than running slowly.
Data access has its own boundaries. History depth depends on the account plan, which means a script that needs several years of intraday bars behaves differently for a free user and a paid one. Second-based timeframes, extended sessions and certain data feeds are also plan-dependent, so test on the plan your users will actually have.
When you are ready to share, a script can stay private, be published open-source for anyone to read and copy, or be published invite-only with the source protected. Invite-only is how commercial indicators are distributed, and it is worth knowing that this is a distribution choice rather than a licensing system: access is granted per username, and support then becomes a job. If your interest is testing an idea rather than selling one, keep the script private and spend the time on backtesting properly instead.
"The first script I wrote made money on every historical chart I put it on. It was reading the closing price of a candle that had not closed yet. Everyone writes that bug once; write it early and cheaply."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- A usable indicator is a version line, a declaration, inputs and a plot, and the version line is the usual reason old code fails to compile.
- The script executes once per bar and re-executes on every tick of the live bar, which is what makes signals appear and disappear.
- Requesting higher-timeframe data with lookahead lets future information reach past bars and invalidates the backtest.
- Pine has no network access, so alerts and webhooks are the only way a script reaches a service outside TradingView.
Frequently Asked Questions
Do I need to be a programmer to write Pine Script?
No, though it helps. Pine is a small domain-specific language with built-in functions for the common calculations, so a working indicator is often twenty lines. The harder part is the execution model, because a script runs once per bar and every variable refers to the value on the bar being processed rather than to a whole dataset.
Why does my indicator look perfect on history and fail live?
Usually because the script reads values that are not final on the developing bar, or requests higher-timeframe data in a way that lets future information reach past bars. On history everything is complete, so the chart looks clean. Confirm signals on bar close and avoid lookahead when requesting other timeframes.
Can a Pine script place trades or call an external API?
Not directly. Pine runs inside TradingView with no network access and no file access, so it cannot reach an external service on its own. The route out is an alert, which can deliver a message to a webhook endpoint that you control, and any order placement happens in that receiving system.