Why Your Price Alert Fired Late, or Did Not Fire at All

An alert fires a minute after the session closed. Another fires while you are watching the chart, and when you look for the signal that caused it, nothing is there.

Both are usually blamed on the platform being slow or unreliable. Neither is a fault. Both follow from documented behaviour, and one of them follows from a rule almost nobody states.

The setting at the centre of it is the alert frequency, and it is more consequential than its position in the dialog suggests.

What an Alert Frequency Setting Actually Controls

An alert has two separate parts. The condition says what must be true. The frequency says how often, once that condition is true, the platform is permitted to tell you.

Those parts are independent. Changing the frequency does not make the condition stricter or looser, and it does not change what the indicator calculates.

What it changes is the number of notifications a single episode can generate, and whether the platform is allowed to speak before the bar is finished.

That second half is where most confusion begins, because a condition can be true for part of a bar and false by the time the bar ends. Whether you hear about that depends entirely on the frequency you chose.

The Four Options, and What Each One Really Does

TradingView’s documentation on alert frequencies lists four choices. The table below restates them and adds the consequence each one carries, which the reference itself does not spell out.

Read as a menu, these look like four degrees of the same thing. They are not. The first three differ in when the platform is allowed to speak, and the fourth differs in how often.

Why a Bar Close Alert Does Not Fire at the Bar Close

This is the mechanism that explains most complaints about late alerts, and it is absent from the articles devoted to this setting.

A bar close alert does not fire because a clock reached a boundary. The server has to establish that the bar really has closed, and that no further trades belonging to it are still to arrive.

TradingView’s documentation states the test plainly: to determine whether the current bar has actually closed, the server waits for the first trade of the new bar.

That is a sound rule. A bar is only provably finished once something belonging to the next one exists. But it has a consequence the reader feels directly.

On an instrument that trades constantly, the first trade of the new bar arrives immediately and the delay is invisible. On a rarely traded instrument, or where there are technical delays, that first trade may appear several seconds after the bar formally closed.

The alert is not late in any meaningful sense. It fires as soon as the close can be confirmed, and confirmation depends on the market, not on the platform.

This is also why two platforms can disagree about when a bar closed at all. Where the daily boundary falls is a separate question, set by the broker’s clock rather than by the charting service, and our page on where the daily bar boundary falls covers that side of it.

The One-Minute Fallback Nobody Documents

The waiting rule raises an obvious problem. If the alert waits for the first trade of the next bar, what happens when no trade ever comes?

That is not a hypothetical. It is the normal state of affairs after a session closes, and on illiquid instruments it can happen inside the session too.

TradingView’s documentation answers it: if there are no trades for too long, the server automatically closes the current bar one minute after its formal close, without waiting for the first trade of the new bar.

The documentation draws the conclusion itself. An alert set on a session close will not trigger at the close, but one minute after it.

This behaviour deserves attention because of where it is written down. It appears in a note about delays, not in the reference page that lists the frequency options.

Anyone reading the frequency reference — which is what most writing on this topic is based on — sees four options and no mention of a fifth behaviour that fires without any trade at all. That is precisely why it is missing almost everywhere else.

Why an Alert Can Fire With Nothing on the Chart

The complaint sounds like one problem: the alert fired, and there is no signal on the chart. It is two problems with two different remedies, and collapsing them is why the fix so often fails.

The first cause is the frequency itself. A once-per-bar alert is permitted to fire mid-bar. If the condition was true while the bar was forming and false again by the close, the alert history records something the finished chart does not show.

Nothing malfunctioned. The condition genuinely was true at the moment it fired. The chart simply does not preserve intermediate states of a bar that has since completed.

The remedy is to move to once per bar close, accepting the confirmation delay described above in exchange for a record that matches the chart.

The second cause is the indicator, not the alert. Some indicators revise their own past output as new data arrives, so a marker that existed when the alert fired is genuinely gone from the chart now.

Here the alert was correct and the chart changed underneath it. Switching frequency will not help, because the instability is in what is being measured. Our page on indicators that repaint covers that behaviour and how to recognise it.

Telling the two apart is straightforward once you know to look. If the condition is stable but the timing was intrabar, it is the first. If the indicator’s own history has changed shape, it is the second.

The same distinction explains a related puzzle. A live alert and a tested signal can disagree on identical data, and our page on why a live alert and a tested signal disagree deals with how a test resolves conditions inside a bar.

An Alert Is Not an Order

Nothing in an alert frequency setting governs whether anything is bought or sold. An alert produces a notification. That is the whole of its effect.

This is worth stating plainly because the settings sit inside a charting environment that also displays broker order panels, and the two are easy to conflate.

The charting service and the execution venue are separate systems, a distinction our overview of the charting platform itself sets out.

The practical consequence is that a late alert costs you information, not a fill. Whether a price was available when the notification arrived is a question about the market and the broker, not about the frequency you selected.

Which Setting Fits Which Question

There is no correct setting here, and any page that names one has skipped the question that determines it: are you watching a level, or confirming a completed condition?

Watching a level is a question about the present. A price is approaching something and you want to know while it is happening. Waiting for a bar to close defeats the purpose.

Confirming a completed condition is a question about the past. You want to know that something finished being true, and an intrabar reading that later reverses is noise.

The choice follows from which of those you are actually asking. It does not follow from which setting is more accurate, because neither is more accurate than the other.

Timeframe interacts with this. A condition on a higher timeframe spends most of its life inside a bar that has not finished, which our page on the higher-timeframe bar that is still forming examines directly.

Who This Page Is Not For

This page will not tell you which alerts to set, on which instruments, at which levels. It describes a mechanism and stops there.

It is also not a comparison. The behaviour documented above is TradingView’s own, described in its documentation, and it should not be assumed to hold on other platforms without checking theirs.

Anyone looking for a setting that removes the trade-off will not find one. Immediacy and confirmation are opposites, and every option above buys one with the other.

Frequently Asked Questions