Pine Script `alert()` vs `alertcondition()` vs Order Fills

The payload is downstream of the trigger. If the wrong Pine primitive emits at the wrong moment, adding route fields will not restore the intended strategy semantics. An indicator has no strategy order fills, while a strategy can use `alert()` calls or order-fill events. `alertcondition()` calls compile in a strategy but do not create usable alert triggers there. Start by writing the exact event in plain language: condition became true, script requested an order, or broker emulator filled a simulated order.

Then decide how dynamic the message must be. `alertcondition()` requires a constant message but can include supported placeholders. `alert()` accepts a series string built at runtime. An order-generating strategy command can carry a dynamic `alert_message`, which is delivered through an order-fill alert when the alert dialog includes `{{strategy.order.alert_message}}`. These capabilities overlap enough to confuse authors, but their trigger moments and script scopes remain distinct.

Each `alertcondition()` call appears as its own option under Condition, which is useful when users should select Long, Short, Exit, or another named event independently. The message cannot concatenate runtime Pine strings because it must be known at compile time. It can, however, contain placeholders for ticker, time, OHLCV, and plotted numeric values. For a static HexTrade route, an alert-dialog JSON template can combine those placeholders with literal account and platform fields.

The trade-off is operational count and duplication. Each active condition is a separate alert, and accidentally leaving an older alert enabled can produce repeated webhooks. Maintain a small inventory with names, versions, symbols, timeframes, and expiration. Since the message is editable in the dialog, source review alone does not prove what is running. Capture the final alert configuration and recreate it after any script, input, chart, or message change.

`alert()` is the flexible choice for calculated quantities, values converted with `str.tostring()`, and messages whose structure depends on direction. Flexibility moves responsibility into code: Pine authors must escape JSON correctly, handle `na`, control repeated calls, and ensure every branch produces the documented receiver contract. TradingView presents all eligible calls through the single “Any alert() function call” choice, so script inputs or branch logic must provide any desired selectivity.

Frequency is not the whole timing model. Indicators can execute on realtime updates, while strategies recalculate at bar close by default unless every-tick behavior is enabled. A strategy configured for every tick can behave differently from historical bars and repaint after reload. For confirmed-bar automation, guard with `barstate.isconfirmed` and use once-per-bar-close. For intrabar logic, document why unconfirmed values are acceptable and test live behavior rather than extrapolating from backtest markers.

Strategy orders can be created on one calculation and filled later under emulator rules. An order-fill alert fires at that emulated fill moment, which can align external routing more closely than an `alert()` emitted when the script merely creates an order. The Pine documentation specifically supports custom messages on `strategy.entry()`, `strategy.order()`, `strategy.exit()`, and `strategy.close()`. Variables in the `alert_message` expression are evaluated when the simulated order executes.

To deliver those custom messages, the running strategy alert must include order-fill events and its Message field must include `{{strategy.order.alert_message}}`. If some order-generating calls omit `alert_message`, that placeholder can resolve to an empty string for those fills. Review every entry, exit, and close path. Also decide whether the alert includes `alert()` calls, order fills, or both; enabling both without distinct intent can send two external instructions for one strategy transition.

Realtime highs, lows, and closes are fluid until the bar confirms. An intrabar `alert()` or `alertcondition()` can legitimately emit on a value that disappears from the historical-looking chart later. Once-per-bar-close reduces this class of discrepancy by waiting for confirmed data, but it also delays the event. Higher-timeframe data and every-tick strategy settings introduce additional repainting considerations. Choose timing according to the strategy's actual requirement, not because one frequency seems universally safer.

At alert creation, TradingView saves the script, inputs, chart symbol, and timeframe as a mirror instance on its servers. Editing any of those later does not update the running alert. This affects all three choices: an old `alertcondition()`, an old `alert()` JSON builder, or an old strategy order-fill message can keep firing. Version labels in documented payload fields help identify stale instances, but the fix is a controlled delete-and-recreate process.

A common double-fire occurs when an `alert()` is called as a strategy creates an order and the same running alert also includes the later order-fill event. Another occurs when separate Long and Short `alertcondition()` instances overlap with an old “Any alert() function call” alert. Inventory active alerts rather than reviewing source code alone. Disable or delete legacy instances, and name new instances with strategy version, symbol, timeframe, and trigger family.

The receiver payload should remain the same documented contract whichever Pine primitive creates it: lowercase platform, exact account ID, destination symbol, supported side or action, quantity, and optional controls. Run `dryRun: true` first. A successful validation proves the message and route can be planned, not that the chosen Pine event corresponds to a live broker fill. Observe one end-to-end order and reconcile the broker before scaling.