An alert on a moving average cross fires at 14:12, the trader takes the entry, and by the close of the same candle the cross has unwound. Nothing malfunctioned. The alert was set to evaluate during the bar, and the condition was true at the moment it was checked. That dropdown decides more about your results than the indicator underneath it.
What you can attach an alert to
Three sources exist. The first is raw price on the symbol: crossing a level, crossing up or down through it, moving above or below, or entering and exiting a channel between two values. The second is any plotted series from an indicator on the chart, which lets you build conditions like "RSI crossing down 70" without writing code. The third is a script that raises its own alert internally, which is how signal indicators deliver a message with entry, stop and target already formatted.
Drawings are the underused option. Attach an alert to a trend line or a horizontal ray and it follows the drawing when you move it, so a support level you redraw each morning keeps its alert without recreating anything. For anyone working the method of marking levels on a higher timeframe and waiting, this is the whole workflow.
The trigger dropdown, in plain terms
| Setting | When it fires | Use it for |
|---|---|---|
| Only once | First time the condition is true, then the alert stops | A single level you want to be told about and then forget |
| Once per bar | The first time it becomes true inside each bar | Fast reaction, accepting that the bar may close differently |
| Once per bar close | Only when the bar closes with the condition true | Confirmed signals, and anything driving an automated action |
| Once per minute | At most one notification per minute while true | Conditions that stay true for long stretches |
Take the bar close option as the default for anything mechanical. Intrabar evaluation is the source of the "signal that vanished" complaint, and it is the same underlying issue as indicator repainting: a value that is provisional until the candle completes.
Writing a message worth receiving
The alert message field accepts placeholders that TradingView substitutes at trigger time. The common ones cover the symbol, the timeframe, the current price, the time of the trigger and the value of a plot on the script. A message that reads "XAUUSD M15 long, price 0000.00" is far more useful at 03:00 on a phone than the default text, because it tells you what to check before you open anything.
For webhook delivery, write the message as JSON instead of prose. The receiving service parses fields rather than guessing at a sentence, and a malformed body is the most common reason an otherwise correct integration does nothing. Keep the schema stable and version it, because an added field breaks a strict parser on the other end.
Webhooks, and the security nobody sets up
A webhook alert posts the message body to a URL you nominate when the condition triggers, which is how a chart condition reaches a Telegram channel, a logging service or an execution bridge within seconds. The mechanism is covered end to end in TradingView webhooks, including payload structure and delivery expectations.
Two controls are worth building on day one. Put a long shared secret inside the JSON body and reject any request that does not carry it, because the endpoint URL is otherwise the only thing standing between your system and anyone who guesses it. And make the receiver idempotent: give each signal an identifier and ignore a repeat, so a retried delivery does not produce a second order. Anything that places trades needs a hard risk gate on the receiving side too, since a chart alert has no concept of your account balance.
Automating an alert into live orders is high risk. A webhook fires on a condition, never on your account state, so position sizing, maximum exposure and a kill switch belong in the receiving service. Test on a demo environment long enough to see how the system behaves on a gap and a disconnection.
The alert log is the second habit worth forming. It records what fired and when, which turns a vague sense that a setup keeps failing into a checkable record you can line up against the chart. Review it weekly alongside the trade journal, delete the conditions that never led anywhere, and rewrite the ones whose message did not tell you enough to act.
Why alerts go quiet
Four causes explain nearly every disappearance. Alerts have a plan-dependent expiration, so an alert created months ago may simply have reached its end date and stopped. Alert counts are capped per plan, and a new alert fails silently when the ceiling is reached. Notification channels are per-alert, so an alert with only the popup channel ticked delivers nothing once the browser is closed, even though the server-side evaluation continues.
The fourth is the one that costs real money. An alert captures the version of the script that existed when it was created. Edit the indicator, save it, and running alerts continue on the old logic. After any change to a Pine script, delete the alerts built on it and recreate them from the updated version. If you are writing your own conditions, the syntax and the alert call itself are covered in Pine Script basics, and the wider platform context sits in what TradingView is.
Keep the total number small. An account with sixty active alerts produces a stream nobody reads, and unread alerts are the same as no alerts. Ten conditions you act on beat sixty you swipe away.
"An alert should be a reason to open the chart, not a reason to press buy. The moment I started treating them that way, the number of trades I took each week halved and the quality went up."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- The trigger frequency setting decides whether a condition is evaluated intrabar or only on the completed candle.
- Alerts run on TradingView servers, but delivery depends on which notification channels the individual alert has enabled.
- Editing a Pine script does not update alerts already running on it; recreate them after every logic change.
- Send webhook payloads as JSON with a shared secret, and make the receiver ignore duplicate deliveries.
Frequently Asked Questions
Do TradingView alerts work when the browser is closed?
Yes. Alerts are evaluated on TradingView servers rather than in the browser tab, so they keep running once created. Delivery to the desktop popup only happens while a session is open, which is why app push and email are the channels to rely on when you are away from the screen.
Why does my alert fire and then the signal disappears?
The condition was true during the bar and false by the time the bar closed. Alerts set to fire once per bar evaluate intrabar, so a condition that depends on the closing value can trigger and then reverse. Setting the trigger to fire once per bar close removes this behaviour at the cost of waiting for the bar to complete.
Does an alert keep the script it was created with?
An alert captures the version of the indicator that existed when it was created. Editing and saving the script afterwards does not update running alerts, so a change in logic only takes effect once the alert is deleted and created again from the updated version.