Alerts & Automation

This page covers what TradingView alerts can and cannot do when attached to Axiom Strategy Lab Pro, and where the gap between the strategy tester's simulation and real-world execution creates risk you need to understa...

Written By Axiom Admin

Last updated About 1 month ago

Alerts & Automation

What alerts can do

TradingView allows you to set alerts on strategy order events — entries, exits, and closes. In the current build, entry orders and non-market exit orders use structured IDs, but MARKET exits triggered through strategy.close() close by the entry order ID and carry the exit name in the order comment instead of a dedicated exit-order ID. That still gives an automation bridge usable order-event detail, but it is not one uniform ID contract across every exit path.

When an alert fires, it means the strategy tester's simulated engine determined that the order should fill based on the current bar's data and the current strategy state.

That is all it means.

The three-model gap

There are three separate models between your backtest and a real trade, and each one has different assumptions:

Model	What it knows	What it does not know
Strategy tester	OHLC prices, fixed slippage, fixed commission, the YAML rules you defined	Real price sequence, real liquidity, real order book, real execution latency
Alert system	That the tester's simulated engine triggered an order event at a specific time	Whether the fill price in the simulation matches what the real market would give
Broker execution	Real order book, real latency, real partial fills, real rejects	Anything about the tester's assumptions or the alert's timing

Each handoff loses information and adds assumptions. Here is how it plays out:

Your strategy's entry condition fires on a bar. The tester determines that a market buy should fill at the next bar's open plus 15 ticks of slippage. It records the fill at that price and updates the equity curve. Now the alert fires — but the alert does not carry the tester's fill price. It carries the fact that the strategy triggered an entry, at roughly the time the script was evaluated. Your automation bridge receives the alert and submits a market buy to your broker. The broker fills it at whatever price the order book gives — which depends on how deep the book is, how large your order is, and how much the price moved between the alert firing and the order arriving. The tester assumed 15 ticks of slippage. The real fill might be 5 ticks, or it might be 50 ticks during a fast move. No one in the chain knows the others' assumptions.

What the alert knows vs. what the broker sees

	Alert (from tester)	Broker (real execution)
Fill price	Computed from OHLC + fixed slippage	Depends on order book depth, order size, market conditions
Fill timing	Bar close or next bar open, depending on `process_orders_on_close`	Depends on network latency, exchange queue, and order type
Partial fills	Never. The tester fills in full or not at all.	Common, especially for limit orders and large positions
Order rejects	Never. The tester always accepts the order.	Possible due to margin, position limits, or exchange rules
Slippage	Fixed at the configured tick value	Variable. Can be zero or can be catastrophic in illiquid conditions.

Real-time evaluation and unconfirmed bars

The strategy script is configured with calc_on_every_tick = true. In real-time (not in backtesting), this means the strategy re-evaluates on every incoming tick, not just on confirmed bar closes.

This matters for alerts because:

An alert can fire on an unconfirmed bar. The condition was true at that tick, but it may become false by the time the bar closes.
If you are routing alerts to an automation system, the automation may submit a real order based on a condition that the strategy will later reverse when the bar confirms.
In backtesting, this setting has no effect — only confirmed bars are evaluated. So your backtest results will not reflect the real-time alert behavior.

If your automation system acts on every alert immediately, you are effectively trading on unconfirmed signals. If your strategy's conditions are sensitive to intra-bar price movement, this can produce trades that the backtest never saw.

When a risk limit halts trading

If one of the four risk circuit breakers trips (max drawdown, consecutive loss days, intraday loss, or intraday order cap), the strategy engine stops submitting new orders. Alerts stop firing. There is no dedicated "trading halted" alert or notification.

From the perspective of an automation system, the strategy simply goes quiet. If your automation expects a certain frequency of signals and the strategy goes silent, you need a way to distinguish "the strategy has no signals right now" from "a risk limit halted everything." The strategy does not help you make that distinction. You would need to monitor the strategy's state independently.

When automation is premature

Automation is premature when:

You have not run the slippage sensitivity test. If your strategy's profitability depends on the tester's fixed slippage model, real execution costs will erode the edge the automation is trying to capture. See Backtesting & Realism.
You have not tested across multiple time windows. A strategy optimized for one regime may fail in the next. Automating a regime-fitted strategy means the automation will faithfully execute a strategy that has stopped working — and it will do so faster than you can intervene.
You have not accounted for the three-model gap. If you are expecting the automation's results to match the backtest's results, you have not accounted for the fill model differences, the alert timing differences, and the broker execution differences described above.
You do not have a manual override plan. Automation does not remove the need for human judgment. It removes the delay between signal and execution — which is useful when the signal is trustworthy and dangerous when it is not.
You are automating to avoid watching. If the reason for automation is that you do not want to monitor the strategy, that is a sign you do not yet trust it enough for automation. Automation should be a reward for strategies that have earned confidence through thorough testing and real-time observation — not a shortcut past the observation step.

The most dangerous path

User sees a good backtest → enables alerts → connects to an automation bridge → goes live.

At each step, something is lost. The backtest's fill model is an idealization. The alert's timing may not match the tester's evaluation cadence. The broker's execution will not match the alert's assumed fill. And the user may not be watching when the strategy enters a regime it was never tested for.

Automation does not make a strategy better. It makes a strategy faster. Faster is only an advantage when the underlying rules are sound and the user understands the conditions under which they stop being sound.

If you do automate, build a monitoring practice around it. Know what the strategy should be doing — how many trades per day or week, what the normal signal frequency looks like. When the frequency changes dramatically, investigate before assuming the strategy adjusted. And have a kill switch — a way to stop the automation that does not require logging into three different systems at 3am.