Why TradingView alerts fire late, twice, or not at all

The whole point of an alert is that you get to stop looking. That’s the entire deal. So when one lands a minute late, or fires four times for a single signal, or just never comes, the damage isn’t the missed trade. It’s that you go back to watching the chart, which is the one thing the alert existed to spare you. Trust is the product here. A flaky alert has negative value.

Almost all of these failures come from a short list of causes, and each has a specific fix. Let me walk the ones I actually see.

“It fired three times for one signal”

Nine times out of ten this is an alert evaluating on every tick instead of once per bar. While the candle is forming, your condition flickers true, false, true as price pushes through the level, and if the alert is set to fire on every trigger, every flicker is another notification.

In Pine you control this at the source. The alert() call takes a frequency argument, and the one you almost always want is once-per-bar-close:

//@version=6
indicator("Clean cross alert", overlay = true)
fast = ta.ema(close, 9)
slow = ta.ema(close, 21)
crossed = ta.crossover(fast, slow)
if crossed and barstate.isconfirmed
    alert("EMA cross up on " + syminfo.ticker, alert.freq_once_per_bar_close)
plot(fast, "fast"), plot(slow, "slow")

The barstate.isconfirmed guard means the condition is only ever checked on a closed bar, and alert.freq_once_per_bar_close means it speaks once. One signal, one alert.

If you’re using the older alertcondition() instead, the frequency isn’t in the code at all. It’s a dropdown in the Create Alert dialog, and the default is “Once Per Bar,” not “Once Per Bar Close.” That single dropdown is responsible for a huge share of duplicate alerts. Set it to Once Per Bar Close and most of the noise just stops.

“It fired, then the signal vanished”

Same root, different bruise. The condition was true for a moment mid-candle, the alert went out, then price pulled back and the bar closed with no signal. The alert wasn’t lying. It honestly reported a moment that didn’t survive to the close. Gate everything on confirmed bars and it can’t happen, because you only ever get told about signals that finished.

“It came a minute late”

This one isn’t a bug and you can’t fix it, only choose it. A genuine closed-bar alert can’t fire until the bar closes. On a 5-minute chart, the soonest you can hear about a 5-minute event is five minutes after it started moving. That delay is the price of confirmation. Want to hear sooner? Drop to a faster timeframe and accept more noise. There’s no setting that hands you confirmation and instant warning together, and anyone selling you both is quietly giving you neither.

“It just stopped”

Before you blame the indicator, check whether the alert is even alive. TradingView alerts expire, and how long they last depends on your plan. They also stop if you hit your account’s active-alert limit, or if you updated the script and the old alert is now pointing at nothing. When alerts go silent, this is the first thing I check, because it’s the most common cause and it has nothing to do with the logic at all.

What I build toward

When I wire alerts into a suite, the bar is simple. It fires once, on the close, for a confirmed condition, and the message tells you enough to act without opening the chart. That last part matters more than people expect. A good message carries the symbol, the level, the direction and the timeframe, built dynamically rather than hardcoded:

alert(str.format("{0} {1} rejected {2} on {3}",
     syminfo.ticker, "SHORT", str.tostring(close), timeframe.period),
     alert.freq_once_per_bar_close)

The moment you feel you have to open the chart to verify an alert, the alert has failed, no matter how clever it was. Fast was never the goal. Trustworthy is. The alert you can act on from your phone, in a queue, without second-guessing, is the only kind worth building.

The useful version

An alert is only useful when you know exactly which moment it is allowed to represent.

These are different alerts:

• condition became true intrabar;
• condition was still true at bar close;
• order filled in the strategy emulator;
• webhook was delivered to a bridge;
• broker or bot acted on that webhook.

If those are blurred together, the trader experiences the alert as “late” or “wrong” even when every component did what it was told.

A concrete debugging pattern

Split live and confirmed logic:

rawSignal = setupCondition
confirmedSignal = barstate.isconfirmed and setupCondition

alertcondition(rawSignal, "Setup forming")
alertcondition(confirmedSignal, "Setup confirmed")

Then name the alert honestly. A forming alert is allowed to disappear. A confirmed alert is allowed to be later. What it cannot be is both early and guaranteed.