Can one TradingView alert check conditions on two symbols?
Not with TradingView's built-in multi-condition alerts. They combine up to five conditions, but every condition has to be on the same symbol. You can still trade a signal that depends on two symbols. Where you build it depends on how much the signal has to remember.
Autoview sits at the end of each option below. It takes one webhook carrying a command and places the order. It doesn't care what sent the webhook, a TradingView alert or a workflow tool. So the question this page answers is where the combined condition gets checked.
Which option fits your signal
| Your signal | Where to check it |
|---|---|
| Up to five conditions, all on one symbol | A TradingView multi-condition alert |
| Conditions on two or more symbols, judged bar by bar | One Pine script that pulls the other symbol with request.security() |
| Conditions that must stay true over time, or that come from different alerts or data sources | A tool outside TradingView that holds the state, such as an n8n workflow |
In every case, Autoview should receive one command when the whole condition is met, not one alert per piece.
Same symbol: a multi-condition alert
TradingView added multi-condition alerts in October 2025. Its Help Center page on them (checked October 3, 2026) sets these rules:
- You can combine up to five conditions, built from price, indicators, or drawings.
- The alert fires only when all of them are true at the same time.
- It needs the Plus plan or higher, and it counts as one technical alert toward your limit.
- All conditions must use the same symbol.
- It doesn't work with strategies or scripts that use the
alert()function, or with scripts older than Pine version 4 that usealertcondition().
TradingView's announcement adds one more limit: multi-condition alerts can't be used as watchlist alerts. You can mix timeframes in one alert. TradingView says it fires once every condition is true, checked at the pace of the smallest timeframe you picked.
If your filters all sit on one chart, this is the simplest setup. Put your Autoview command in the alert message and your Autoview webhook URL in the alert's webhook field, the same as any other alert. The alert setup guide walks through those two fields.
One note if an AI agent builds your alerts through TradingView's MCP server: when we read its alert tool's schema on September 29, 2026, it listed multi-condition alerts as not supported yet. Create this kind in the chart's alert dialog instead.
Two symbols: one Pine script
A multi-condition alert can't look at a second symbol, but a Pine script can. The request.security() function asks for another symbol's data and runs an expression on that symbol's own bars. Its first three arguments, per TradingView's Pine v6 manual, are symbol, timeframe, and expression.
Here's a common case: buy an altcoin when it closes above its 50 EMA, but only while BTC is above its own 200 EMA. The script runs on the altcoin's chart.
//@version=6
indicator("Alt above EMA, BTC filter", overlay = true)
btcSymbol = input.symbol("BINANCE:BTCUSDT", "Filter symbol")
// Chart symbol: close above its 50 EMA
altAbove = close > ta.ema(close, 50)
// Second symbol: the expression runs on BTC's own bars
btcAbove = request.security(btcSymbol, timeframe.period, close > ta.ema(close, 200))
entry = altAbove and btcAbove
// Fire only on the bar where the combined condition turns true
if entry and not entry[1]
alert("s=ETHUSDT b=buy q=1 t=market d=1", alert.freq_once_per_bar_close)What each part does:
close > ta.ema(close, 200)insiderequest.security()is calculated on BTC's data, so you get BTC's 200 EMA, not the altcoin's.timeframe.periodkeeps the BTC check on the same timeframe as your chart.entry and not entry[1] sends the command once, on the bar where both conditions first agree, instead of on every bar they stay true.alert.freq_once_per_bar_closewaits for the bar to close. Pine's alerts manual says the default frequency fires on the first call in a realtime bar, while prices are still moving.- The message is the Autoview command. Replace the symbol and size with your own, and keep
d=1while you test so Autoview logs the order without placing it.
To arm it, add the script to the chart, create an alert, choose the script as the condition and its alert() function calls as the trigger, then add your Autoview webhook URL. Because this script uses alert(), it can't be part of a multi-condition alert. It doesn't need to be, since the script already combines the conditions.
Two cautions from the same Pine manual:
- Leave lookahead off.
request.security()defaults tolookahead = barmerge.lookahead_off. Turning lookahead on without offsetting the expression pulls future higher-timeframe values into historical bars, so the chart's history looks better than anything that could run live. - The other symbol moves mid-bar too. On a realtime bar, the requested value is the most recent developing one. Firing once per bar close keeps a brief move in BTC from sending a trade that wouldn't hold to the close.
If your filter uses a higher timeframe, such as BTC's daily trend on a 1-hour chart, the manual's non-repainting pattern is to offset the expression by one bar and turn lookahead on, so you always read the last finished daily bar:
btcDailyUp = request.security(btcSymbol, "D", close[1] > ta.ema(close, 200)[1], lookahead = barmerge.lookahead_on)
State that has to hold: keep it outside TradingView
A script is good at "both of these are true on this bar." It gets awkward when the signal has to remember things. Maybe BTC needs to have held its filter for the last several hours, or a volatility reading comes from a feed TradingView doesn't chart. Or the pieces live in separate alerts from different scripts or charts. One trader on r/algotrading described this point as "using alerts as a tiny state machine."
If every input is a TradingView symbol, try a script first. A script can count how many bars in a row its combined condition has held. Move the state out once it spans alerts or data a single script can't see.
When you do, the pattern looks like this:
- Each condition sends its own alert to a tool that can store state, not to Autoview.
- That tool keeps the latest reading for each symbol and checks the combined rule every time a new alert arrives.
- When the rule resolves, it sends one command to your Autoview webhook.
n8n is a common choice for this. The n8n signal page shows how to set up the HTTP Request node that sends the final command to Autoview, including how to build the command from values the workflow worked out earlier. Autoview only sees that last command. Your workflow makes the decision, and Autoview places the order.
Stop the relay from sending twice
Once a relay sits between your alerts and Autoview, guarding against duplicates is the relay's job. Two facts matter here:
- Autoview won't catch a repeat on the webhook platform. The
dedupe=parameter is accepted there but not compared, so it doesn't block a second copy of the same command. The duplicate orders guide covers wherededupe=does and doesn't apply. - TradingView may resend to your relay. TradingView resends a webhook when the receiving server answers with a status from 500 to 599, except 504, up to three times. Your relay is that receiving server now. See does TradingView resend a webhook alert for the exact policy.
So have the relay record each signal it has acted on and skip any repeat of it. Test the whole chain with d=1 in the command, then read the log to confirm exactly one command arrived per signal before you remove it.
A note on what Autoview is. Autoview is an execution tool, not a trading or investment advisor. It places the orders your alerts and workflows tell it to; it doesn't generate signals or make any claim about results. Trading carries risk of loss, and you're responsible for the strategy you automate. See our disclosures.