TradingView Alert Triggered Too Often: Fix and Restart

The orders were arriving, then the account went quiet. TradingView says “Alert was triggered too often and stopped.” Changing the broker connection will not fix this particular message: the alert has stopped at its source.

TradingView limits a regular alert to 15 triggers in three minutes. Its Pine documentation says that exceeding this frequency halts further alerts. AlgoWay receives the trading instructions that TradingView sends; it cannot execute an instruction that the stopped alert never emits. First confirm the stop, then reduce the unwanted triggers and reconcile the real account before starting a replacement alert.

Published: September 25, 2026 · Author: AlgoWay

What the 15-trigger limit actually measures

This is a trigger-frequency limit for a regular alert, not the number of alerts saved in your account and not a count of broker fills. One trigger and one resulting trade are different events. A request may fail after an alert fires, and a trading instruction can produce more than one execution operation.

Watchlist alerts have separate rules: TradingView documents a 15-trigger limit per symbol in three minutes and a 1,000-trigger limit for the entire watchlist alert over that interval. A symbol can stop while the other symbols continue. Do not apply the regular-alert diagnosis to a watchlist without checking which part stopped. See TradingView’s current trigger limits.

Count the events belonging to the affected alert around the stop time. Do not add every webhook entry from unrelated strategies and call that TradingView’s count. Equally, a quiet five-minute average can hide a busy three-minute burst.

Find where the instructions stopped

Use the same time interval in all three places, allowing for different displayed time zones. The last successful trade is a useful starting point, but it is not necessarily the last alert.

Evidence	What it establishes	Next check
TradingView marks the alert stopped for excessive triggers.	The alert source has stopped producing further events.	Inspect its recent trigger sequence and selected event types.
TradingView records an alert, but you cannot find its request in AlgoWay Webhook Logs.	You have not yet confirmed receipt by AlgoWay.	Check the selected route, webhook notification setting, delivery status and matching timestamp. Absence from one log view alone does not establish the cause.
AlgoWay Webhook Logs contain the matching request.	That instruction reached AlgoWay.	Read its response and check the destination’s order history. Receipt is not proof of a fill.
The destination shows a rejected order.	The investigation has reached execution.	Use the reported rejection reason. For MT5, the Error 4756 guide explains how to investigate volume, stops and other broker restrictions.

A successful AlgoWay test checks the route used by that test. It does not prove that the stopped TradingView alert has resumed. Conversely, recreating the alert does not prove that the destination accepted the next order. Keep those checks separate.

Reduce repeated events at the source

First decide what should count as a new instruction. “The buy condition remains true” and “a new buy signal has appeared” are different rules. If the intended behavior is one entry when a condition changes, repeatedly announcing the same state only adds traffic.

For explicit Pine alert() calls, the frequency argument matters:

Setting	Behavior
`alert.freq_all`	Allows every executed call during the realtime bar to trigger.
`alert.freq_once_per_bar`	Allows the first call during each realtime bar.
`alert.freq_once_per_bar_close`	Requires the call to execute on the realtime bar’s closing update.

Strategies normally calculate at bar close; enabling calc_on_every_tick allows intrabar calculations. These frequency arguments govern alert() calls, not strategy order-fill events. TradingView explains both event types in its Pine alert documentation.

“Once per bar” is not a universal cure. As a simple calculation, one event on every 10-second bar produces 18 events in three minutes. Bar-close timing also changes when a signal becomes actionable. Use it only if that matches the strategy’s intended timing.

Check whether the strategy alert includes both order fills and alert() calls. If both describe the same intended trade, selecting both can send redundant instructions. Choose the event source your message was designed for; the AlgoWay Pine alert examples explain the corresponding message setup.

If editing the script, separate entry throttling from position-management logic. A blanket “ignore everything for three minutes” rule could silence an exit as readily as a repeated entry. Do not solve a noisy entry by making the exit inaudible.

Reconcile the account before restarting

Consider a simple failure: an entry reached the account, the alert stopped, and the strategy later showed an exit on the chart. The chart’s position and the real account’s position may now differ. Treat that as a state mismatch to investigate, not an invitation to resend every old message.

Record the affected alert and stop time. Preserve the recent trigger history and corresponding AlgoWay responses so you can explain the gap.
Inspect the destination account. Check actual open positions, pending orders and accepted protective orders. A stop or target drawn on a chart is not evidence of an accepted order at the destination.
Resolve any mismatch deliberately. Determine how the next valid instruction should behave against the account’s current exposure. Do not blindly replay stale entries or exits: some earlier requests may already have executed.
Correct the repeated-trigger cause. Review event selection, condition transitions and timing. Keep the required exit behavior intact.
Create the replacement alert from the corrected setup. TradingView stores a snapshot of the script, inputs and chart context when an alert is created. Editing the chart or script does not update that snapshot; its documentation instructs users to delete the old alert and create a new one. Preserve the needed diagnostic record first. See the alert snapshot explanation.
Verify a fresh event through the whole route. Use a demo or test destination where available. Match the new TradingView event to AlgoWay Webhook Logs and then to the destination’s actual response. Test the intended exit as well as the entry.

Leave only the intended alert active when replacing the old setup. Two active copies can produce a new duplication problem while you are fixing the original one.

The useful evidence after the repair is modest: the alert stays active during the triggering conditions you tested, each intended instruction is identifiable in AlgoWay, and the destination account ends in the state you expected. Keep that record. It is more persuasive than a chart that merely looks busy.