alertcondition() in Pine Script defines a selectable alert condition for an indicator, using a constant message that can contain placeholders. alert() works in indicators and strategies, accepts a message built at runtime and sets its frequency in code. Neither function creates a running TradingView alert: the user must create one in the alert dialog. Choose between them by script type, message needs and the event you intend to send.
Part of the Pine Script guide and function reference. The comparison below describes Pine Script v6 as of 25 September 2026, including the difference between an alert event and a broker order.
alertcondition() vs alert() at a glance
TradingView documents two indicator mechanisms and a separate strategy order-fill mechanism.[1][2]
Scroll horizontally to read every column.
| Feature | alertcondition() | alert() |
|---|---|---|
| Usable script type | Indicator | Indicator or strategy |
| Where the call goes | Global scope, outside conditional blocks | Usually inside an if block |
| Condition | A true-or-false argument | The surrounding code decides whether to call it |
| Message | Constant string; supported placeholders supply changing values | Series string assembled at runtime; placeholders are not processed |
| Frequency | Selected in the alert dialog | The freq argument in code |
| Alert selection | Each call exposes a named condition | One selection listens to eligible alert() calls |
What do the signatures mean?
alertcondition(condition, title, message)
condition is a required series boolean: true or false on each evaluation. The optional title and message are constant strings, known when the script compiles. The title identifies the condition in the alert dialog; the message supplies editable default text.[1]
Keep the call at the script's global scope. Put the complete boolean expression in its first argument instead of placing the call inside if. A true condition makes an event eligible; a running alert and its frequency rules still determine whether it fires.
alert(message, freq)
message is a series string, so it can include calculated values converted with str.tostring(). The function has no condition argument. An if block normally controls when the call executes.[1]
-
alert.freq_once_per_baris the default: it permits the first eligible call on a realtime bar. -
alert.freq_once_per_bar_closerequires a call during the realtime bar's closing execution. -
alert.freq_allpermits all eligible calls on the realtime bar.
Frequency does not make a script execute more often. A strategy normally calculates at bar close; using alert.freq_all alone does not enable intrabar calculation.[1] The alert() function guide covers the runtime-message route in more detail.
Worked example: true during the bar, false at the close
Illustrative numbers, not a recommendation. Consider an indicator condition close > open on a realtime bar with an opening value of 100. The changing close value is the latest price update, not a final closing price until the bar ends.[3]
| Evaluation | Current value | Above the opening 100? |
|---|---|---|
| First update in this illustration | 99 | False: 99 < 100 |
| Later update | 102 | True: 102 > 100 |
| Closing update | 100 | False: equality is not greater than |
Assume an active alert with no earlier trigger on this bar. A once-per-bar alert can fire at 102. A once-per-bar-close alert produces zero events here because the condition is false at the close. Both mechanisms can express these timing choices.
The closing frequency does not queue the earlier true condition. Nor does it retract an alert that already fired intrabar.[1] The barstate.isconfirmed reference explains how a script can explicitly restrict a condition to the closing update.
How do constant messages contain changing values?
A constant template and a constant delivered message are different things. An alertcondition() message such as Close={{close}} is fixed in the source, but TradingView substitutes the bar's value when the alert triggers.[1]
Numeric plot values can use {{plot_0}} or a named placeholder such as {{plot("Score")}}, provided the script has the corresponding plot. A named placeholder uses the plot title, not the variable name. Arbitrary string variables cannot be inserted through plot placeholders.
Illustrative sketch; not compiled or tested. Paste into TradingView's Pine Editor as an indicator. The two routes below emit diagnostic text, not PineConnector instructions. Create an alert for one route to inspect its message; the sketch does not create that alert itself.[1][6]
//@version=6
indicator("Alert message comparison")
ready = barstate.isconfirmed and close > open
alertcondition(ready, "Closed above open", "Close={{close}}")
if ready
alert("Close=" + str.tostring(close), alert.freq_once_per_bar_close)
Select Closed above open for the alertcondition() route, or Any alert() function call for the runtime route. The former populates the dialog's Message field. The latter takes its text from the script and does not process {{close}} placeholders.[2]
Which route fits webhook automation?
The deciding factor is where the message must be assembled. An indicator with separate named conditions and a fixed instruction can use alertcondition(). A script that assembles changing text, chooses messages in branches or is a strategy can use alert().
For PineConnector, either route still needs a complete instruction matching the PineConnector Syntax reference.[4] A chart ticker placeholder does not establish the broker's symbol name. Match the exact symbol, including any prefix or suffix.
PineConnector's manual alert integration examples document alert() calls for indicators and strategies.[5] Follow the message through these distinct stages:
- The defined condition is true at the intended evaluation time.
- The active TradingView alert triggers with the intended message.
- The webhook delivers the message to PineConnector.
- PineConnector processes it; the receiving EA can then submit an order request.
- The broker accepts or rejects the request. Check any resulting deal and position separately.
The demo verification procedure compares the TradingView log, the processing record and the broker account.[7] An alert log entry establishes a trigger, not the final position.
Why can alertcondition() fail or send the wrong event?
-
Strategy mismatch:
alertcondition()in a strategy does not provide usable alert conditions, even though its presence need not cause a compilation error.[1] -
Wrong message type: concatenating a changing value into
alertcondition()breaks its constant-string requirement. Use a supported placeholder or the runtime route. - Overlapping routes: a strategy can alert on calls, simulated order fills, or both. A condition event and a simulated fill are distinct events; configuring both for the same intended action can duplicate requests.[1]
- State mistaken for a cross: “above” can stay true on successive bars. Frequency does not turn it into a one-time transition; see crossover and crossunder event definitions.
- Stale snapshot: editing code, inputs, symbol or timeframe does not update an existing alert. Recreate the affected alert and retire the superseded copy.[2]
- Historical expectation: script alerts fire on realtime bars. Historical markers do not replay old notifications when an alert is created.[1]
Bar-close timing addresses the illustrated intrabar change. It does not make unfinished higher-timeframe inputs final or eliminate every cause of repainting.[1]
Frequently asked questions
What is alertcondition() in Pine Script?
alertcondition() defines a named alert condition in a TradingView indicator. Its first argument is a true-or-false series; its title and message are constant strings. The message can contain supported placeholders. The function exposes an option in the alert dialog, but the user must create a running alert and select its frequency.
What is the difference between alertcondition() and alert()?
alertcondition() exposes individual indicator conditions and uses constant message templates with optional placeholders. alert() works in indicators and strategies, accepts text assembled at runtime and sets frequency in code. A runtime call's message comes from the script, while an alertcondition message can be edited in the alert dialog.
Can I use alertcondition() in a strategy?
A Pine Script strategy can contain alertcondition() without that call necessarily causing a compilation error, but users cannot create alerts from those conditions. Strategies instead support alert() calls and simulated order-fill events. Choose the event deliberately: a script condition becoming true is different from the broker emulator filling an order.
Does once per bar close remember an earlier signal?
No. With alert.freq_once_per_bar_close, an alert() call must execute during the realtime bar's closing execution. A condition that was true earlier but is false at the close does not produce a closing event by itself. Recording an earlier event requires separate state logic and changes the rule being implemented.
Reviewed 25 September 2026. Facts were checked against the linked sources on that date. Nothing in this article was tested on a trading account and no code was compiled.
Related reading
- Pine Script guide and function reference
- The alert() function for automated signals
- barstate.isconfirmed and bar-close signals
- Crossover and crossunder events
Sources
- TradingView – Pine Script v6: Alerts, accessed 25 September 2026.
- TradingView – Pine Script FAQ: Alerts, accessed 25 September 2026.
- TradingView – Execution model, accessed 25 September 2026.
- PineConnector – PineConnector Syntax, accessed 25 September 2026.
- PineConnector – Add alerts to your script, accessed 25 September 2026.
- TradingView – Pine Script v6 Reference Manual, accessed 25 September 2026.
- PineConnector – Test your setup, accessed 25 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.
