Pine Script Alerts for TradingView Automation

Indicators, Strategies and Alert Triggers

An indicator can mark a condition without creating an executable account instruction. A strategy can simulate entries and exits without placing them at your broker. The automation task is to select a suitable event, encode its meaning and connect it to execution.

TradingView documents different alert mechanisms for these jobs. ^{[S04] [S29]}

Code that defines an alert trigger does not itself create the user's running alert. Confirm the condition selected in the alert dialog and record it with the strategy settings.

Order Fills Versus alert() Calls

Emulator fills

A strategy fill is an event in TradingView's broker emulator. It is not a notification that your external broker filled an order. The strategy's simulated position and the account's actual position can therefore diverge. TradingView describes the emulator and execution timing in its strategy documentation. ^[S28]

Signal timing

A signal at the moment an order is requested and a signal at the simulated fill can occur at different times. Decide which one the execution route expects. For a limit-order workflow, sending an instruction only after a simulated fill is a different design from placing a real limit order as soon as the strategy requests it.

Write down this choice before adapting someone else's script. “Automate the strategy” is too vague when the strategy uses pending orders, multiple exits or intrabar calculations.

Duplicate execution paths

A strategy can contain alert() calls while also generating order-fill events. Selecting both event types can send messages for both paths. The right test is to examine each outgoing message and establish whether both describe one intended account action.

For example, an entry condition can emit a custom buy message and later produce an order-fill message. A receiver that opens on each will see two instructions. Changing the broker's lot multiplier would hide neither the duplicate source nor the faulty event selection.

Messages and Placeholders

Order-specific alert_message values are delivered through the strategy.order.alert_message placeholder in the appropriate order-fill alert message. In contrast, an alert() message is assembled within the script. These mechanisms should be configured deliberately rather than layered together blindly. ^[S29]

Before connecting a strategy, inventory its messages:

This inventory is an execution contract. It tells you whether a receiver can represent the strategy without translating a close into a new entry. Read the webhook examples for the transport format and the market-specific guide for destination constraints.

Bar Close, Intrabar Calculation and Repainting

A condition can become true during an unfinished bar and be false by its close. A historical chart cannot be treated as a complete record of every realtime update. TradingView's repainting documentation explains differences between historical and realtime calculation. ^[S05]

Waiting for bar close changes the event definition. It can remove some intrabar ambiguity, but it also changes when a trade is requested. It is not a universal repair for every strategy, nor does it make all higher-timeframe logic safe.

Check the script's calculation settings, data requests and intended confirmation point together. A higher-timeframe value that is still developing deserves particular attention. Keep one recorded example of the source bar, the alert time and the later chart state.

A useful comparison has three columns: historical strategy trades, realtime emitted alerts and actual account fills. Match individual events rather than comparing only the final net profit. Missing alerts and different fill prices are different problems.

A TradingView Reddit discussion about differences between Strategy Tester trades and alert records illustrates why this comparison matters. The report does not establish a universal platform fault or diagnose your script. Use it as a prompt to inspect a specific event, then use the official calculation and alert documentation to explain it. ^[R02]

Why Existing Alerts Keep Old Settings

A created TradingView alert retains a server-side snapshot of the script, its inputs and chart context. Editing the chart's script settings does not update that existing snapshot. Recreate the affected alert through the documented workflow after a change. ^[S04]

Use a descriptive alert name containing the strategy revision, symbol and timeframe. This is an operational convention, not a required TradingView naming syntax. It makes an old instance easier to spot when the chart shows one version and the alert uses another.

Before replacing an execution alert, record its message, URL and condition. Check the destination's current positions and pending orders. Updating the signal generator does not automatically reconcile positions opened by the old version. The troubleshooting guide explains how to compare the records.

Questions and Answers

Why did changing my script not change the alert?

The running alert uses the snapshot created with it. Update the alert using TradingView's documented recreation process and verify the replacement on a test route.

Can I automate a closed-source indicator?

Only through events and values the author exposes. Visible arrows alone do not provide a machine-readable entry, exit or stop value. Check available alert conditions and documentation before buying a bridge.

Why does the chart show trades that were never alerted?

A chart can show historical simulated trades, while alerts operate on realtime events. Calculation differences and later chart recalculation can also matter. Match the timestamp and settings of a specific case; do not infer missing webhooks from the chart alone. ^[S06]

Why is a reversal larger than the new target position?

TradingView strategy reversal behavior can include the quantity needed to close existing simulated exposure as well as establish the new side. Confirm what the receiver expects: transaction size or target position. ^[S28]