TradingView Alerts: Setup, Limits and Practical Use
Alerts in TradingView fire when price or an indicator condition is met, even if your browser is closed. You create them from the chart, pick once-only or repeating, set expiry, and optionally send a webhook. Plan limits cap how many can run at once.
How alerts on TradingView actually fire
TradingView evaluates your condition on its servers using the chart’s symbol, timeframe and the last confirmed bar unless you choose otherwise. A price alert on a 15-minute EURUSD chart checks that 15-minute close (or the intra-bar tick if you enable it). Indicator alerts use the script’s plot or alertcondition output. If the script repaints, the alert can fire on a value that later disappears. Non-repainting scripts keep the signal stable after the bar closes.
You can run alerts while logged out. They do not require the chart to stay open. Notifications go to the app, email, SMS (paid plans) or a webhook URL. Trading still involves risk; an alert is a decision-support ping, not an order.
Create an alert, step by step
- Open the chart, right-click the pane or click the alarm-clock icon in the top toolbar.
- Choose the condition: price (crossing, greater than, less than, entering channel), an indicator plot, or a drawing (trend line, horizontal).
- Set frequency: Once (fires then auto-stops), Once Per Bar Close (safest for most strategies), or Once Per Bar / Every Time (can spam on ticks).
- Add an expiration date or leave it open until you cancel it.
- Write a short message. You can insert placeholders such as {{ticker}}, {{close}}, {{interval}} so the notification is readable on a phone.
- Optional: paste a webhook URL if you route the ping to a bot or logger. Test the URL first with a dummy payload.
- Save. The alert appears in the Alerts panel (clock icon). You can pause, edit or delete it there without touching the chart.
For a crossing alert, pick “Crossing” rather than “Crossing Up” if you only care that the level was touched. Crossing Up / Down reduces noise on mean-reverting names.
Useful condition types
- Price crossing a round number or prior day high/low.
- Indicator plot crossing zero or a moving average you added to the same pane.
- Two plots of the same script (for example a fast and slow line) crossing each other.
- A drawing: alert when price touches a ray or rectangle you placed for a session high.
Keep the condition simple. Nested “and” logic is easier to debug in Pine than in the alert dialog.
Plan limits you will hit
Free accounts allow a small number of concurrent alerts. Paid plans raise the cap and unlock SMS plus more webhook options. Exact numbers change with TradingView’s pricing page, so check your account’s Alerts panel: it shows how many slots you have left. If you run many symbols, you will need more slots or you must delete stale alerts. Webhooks on lower tiers may be restricted; confirm before you build an automation chain.
Alerts count per account, not per chart. Ten charts with one alert each still use ten slots. Recurring “every tick” alerts consume the same slot as a once-per-bar-close alert.
Pine Script alerts versus dialog alerts
Custom scripts can expose alertcondition() so the dialog lists a named event, or they can call alert() inside the script so a single saved alert on that script fires with a dynamic message. The second method is cleaner when the logic is complex (BOS, FVG fill, session open). Use barstate.isconfirmed or calculate on close so the alert does not fire on a wick that later retraces.
ZynIQ indicators are Pine Script v6, non-repainting, and work on any TradingView plan including free. You still create the alert yourself in the dialog; the script only supplies a stable condition. Instant source download after checkout lets you read the alert() calls before you trust them.
Once per bar close versus every tick
Once Per Bar Close waits for the candle to finish. That matches how most backtests treat a signal. Every Time / Once Per Bar can fire mid-bar; on a 1-minute crypto chart that may mean dozens of pings during a spike. Use tick alerts only when you need a liquidity sweep or a stop-hunt level and you accept the extra noise.
Webhooks without turning them into a black box
A webhook is an HTTP POST to a URL you control. TradingView sends JSON with the message you wrote. Your endpoint must answer quickly (a few seconds) or TradingView may retry or drop it. Do not put API keys in the alert message; keep secrets on the receiving server. Test with a request bin first. If you connect a trading bot, size risk on the bot side. An alert is not a fill.
Rate limits exist. Bursting 50 alerts in one minute can delay later ones. Stagger symbols or use a coarser timeframe if you hit delays.
Mistakes that waste slots and trust
- Leaving expired drawings on the chart: the alert still references them until you delete the alert.
- Using a repainting oscillator: the ping arrives, then the plot moves away on the next tick.
- Alerting on the wrong timeframe: a daily condition on a 5-minute chart still evaluates the daily series, but the chart you stare at will not match the ping.
- Forgetting timezone: session alerts follow the chart’s exchange timezone, not your laptop clock.
- Never reviewing the Alerts log: failed webhooks show there.
Set a weekly calendar reminder to prune alerts. Dead alerts on delisted tickers still occupy slots on some plans.
Risk checks before you act on a ping
An alert does not know your position size, spread or news calendar. Treat it as a cue to look at the chart, not as an instruction to click buy. Check spread and session: a London open alert on GBPJPY can print during a wide spread. Confirm the bar has closed if you chose Once Per Bar Close. If you use indicators for market structure, liquidity or FVG, verify the swing is still valid after the alert. Trading involves risk of loss. No indicator or alert changes that.
For multi-asset use (stocks, forex, crypto, futures) keep separate alert folders in your head: equity alerts often need earnings blackouts; crypto alerts need funding-time awareness. The dialog does not enforce those filters; you do.
| Setting | Typical use | Watch-out |
|---|---|---|
| Once | Break of a well-defined level | You must recreate it after it fires |
| Once Per Bar Close | Structure or FVG logic | Slight delay vs last tick |
| Every Time | Intraday stop or sweep | Noise and slot waste |
| Webhook | Log or bot handshake | Your server must stay up |
Keep messages short. Phone notifications truncate; put the ticker and the reason in the first 40 characters.
Frequently asked questions
Do TradingView alerts work when the browser is closed?
Yes. They run on TradingView’s servers. You still need an active alert slot and a working notification method (app, email, SMS or webhook).
How many alerts can I run at once?
It depends on your plan. Free accounts have a small cap; paid plans raise it. Check the Alerts panel in your account for the live number rather than an old blog post.
Should I use Once Per Bar Close or Every Time?
Use Once Per Bar Close for most strategy-style conditions so the signal matches a closed candle. Use Every Time only when you need intra-bar events and can tolerate extra pings.
Can a custom indicator send its own alert text?
Yes, if the script calls alert() or exposes alertcondition(). You still create one alert on that script in the dialog. Non-repainting scripts keep the message aligned with the closed bar.
Are webhooks the same as placing an order?
No. A webhook is only an HTTP message. Any order logic, sizing and broker connection sit on your side. Trading involves risk; test the full path with tiny size or paper first.
Why did my alert fire then the plot moved?
The script likely repaints or you chose a tick-based frequency. Switch to bar-close evaluation and a non-repainting condition, then recreate the alert.