Growth ClubGrowth Club
The methodHow it worksIndicatorResultsInsightsFAQ
Log inGet access
© 2026 Growth Club← Back to home
Chat with us
← All insights
Trading toolsSep 10, 2026

TradingView alerts: what each setting actually does

Once Per Bar vs Once Per Bar Close, alert() vs alertcondition(), webhooks, and the timeframe-binding mistake that makes people think an indicator has stopped working.

TradingView's alert dialog looks simple and hides two decisions that change what you receive. Get either wrong and you will either miss the trades you set the alert for, or be woken by alerts for trades that never happened.

Here is what each option means in practice.

Once Per Bar vs Once Per Bar Close

This is the setting that matters most, and the one most often left on the wrong value.

Once Per Bar fires the moment the condition becomes true, mid-candle. The candle is still forming. Price can move back the other way before the candle closes, at which point the condition may no longer be true — but the alert has already been sent.

Once Per Bar Close waits for the candle to finish and only fires if the condition is true at that final price.

The difference is not cosmetic. Consider a strategy that triggers when price crosses above a moving average. At 14:32, four minutes into a five-minute candle, price ticks above the average — Once Per Bar fires immediately. Over the next 60 seconds price falls back below. The candle closes below the average. The signal, as your strategy defines it, never existed.

You now have an alert for a trade your own rules did not generate.

This is what people mean by a "repainting" alert, though the indicator is not really repainting — the alert is simply reporting a provisional state as though it were final.

Once Per Bar Close is the correct default for any strategy defined on closes. The cost is that you learn about the signal at the close rather than during the bar. On a 5-minute chart that is up to five minutes late. That lateness is the price of the signal being real.

Use Once Per Bar deliberately, not by accident — for something like a price level being touched, where the touch itself is the event and confirmation is not the point.

Alert conditions: alertcondition() vs alert()

Pine offers two mechanisms, and which one an indicator uses determines what you see in the dropdown.

alertcondition() is declared at the top level of the script. Each one appears as a separate, named entry in the condition list. If a script declares three, you get three choices — and if you want all three, you create three alerts.

Its limitation: the message is largely fixed at creation. It can include placeholders such as {{ticker}}, {{interval}} and {{close}}, but it cannot easily carry values the script calculated, like a stop price or a target.

alert() is called from inside the script's logic, at the moment something happens, and takes a string built at that point. That string can contain anything the script knows — entry, stop, four targets, the reason a trade closed.

Scripts using alert() present a single dropdown entry, usually worded like "Any alert() function call". Selecting it means you receive every alert() the script fires, of every kind, through one alert.

That is a genuine advantage: one alert covering an entire trade lifecycle — signal armed, order filled, order cancelled, trade closed — rather than four separate alerts to create and keep in sync. It is why an indicator's setup instructions may tell you to pick that option specifically rather than a named condition.

Expiry

Alerts have an expiry date, and on lower tiers TradingView will not let you set them to never expire. An alert that silently stopped days ago looks exactly like a market that has not produced a signal.

If you rely on alerts, check the expiry when you create them and note when they lapse. "The indicator stopped working" is, more often than not, an expired alert.

Webhooks

Any alert can POST its message to a URL. The message body is sent as-is, so if the script builds JSON, that JSON arrives at your endpoint.

Three things worth knowing before you build on it:

  • The message is the payload. There is no separate structured object. Whatever you want on the other end must be inside the alert text.
  • Delivery is not guaranteed. It is a fire-and-forget HTTP request. Your endpoint must be up, fast, and tolerant of duplicates.
  • The endpoint is public. Anyone who learns the URL can post to it. Authenticate the request — a shared secret in the payload, or a token in the URL — and validate before acting.

A sensible default setup

For a strategy defined on candle closes:

  1. Right-click the chart → Add alert.
  2. Set Condition to the indicator, not to the symbol. Selecting the symbol gives you a price alert, which is not what you want.
  3. If the script uses alert(), choose Any alert() function call. Otherwise pick the named condition you need.
  4. Set Once Per Bar Close.
  5. Choose delivery — app notification, email, webhook. App notifications on a phone are the most reliable of the three for most people.
  6. Check the expiry date before saving.

The mistake worth avoiding

The most common failure is not a wrong setting. It is creating the alert on one timeframe, then changing the chart's timeframe afterwards.

An alert is bound to the chart state it was created on. Setting an alert on the 5-minute chart and later switching that chart to 1-hour does not move the alert — it continues to evaluate on 5-minute bars. This is usually what people have run into when alert frequency does not match what they see on screen.

If you trade two timeframes, create the alert for each on a chart set to that timeframe, and name them so you can tell them apart later.


Educational content, not financial advice. Trading leveraged instruments carries significant risk of loss.

Want live XAU/USD signals with risk management built in?

Get access