Alerts
The Base trim ships with ten alert conditions. Every one of them is a **state alert** — a condition that evaluates to true on every confirmed chart bar where the condition holds, and false otherwise. None of them are...
Written By Axiom Admin
Last updated 22 days ago
Alerts
The Base trim ships with ten alert conditions. Every one of them is a state alert — a condition that evaluates to true on every confirmed chart bar where the condition holds, and false otherwise. None of them are transition alerts. That distinction is the most important paragraph on this page. If you read nothing else, read the "state vs. transition" block below, because it determines whether these alerts will feel useful or frustrating in your workflow.
The ten conditions at a glance
Ten conditions, three groups. No other alerts ship. That is deliberate.
State vs. transition — the distinction that matters
Every alert here describes an ongoing state on a confirmed chart bar. There is no Just Crossed Bullish or Just Flipped condition anywhere in the script. The practical consequence:
If slot 01 is bullish for fifteen consecutive confirmed chart bars, and you wire the
MACD 01 Is Bullishalert to "Once per bar close," you will get fifteen notifications — one per bar, every bar the state holds.If you wire the same alert to "Only once" in TradingView, you will get one notification on the first bar the state is true, and nothing else until you reset the alert — which is closer to a transition experience, but you should not confuse "firing only once because TradingView deduplicated" with "firing on a flip."
If you need a true crossover or flip notification, you need to build it yourself — wire two alerts and handle the transition in your downstream system, or use TradingView's alert-on-condition-change tooling against the plotted series. The indicator does not ship a transition alert in this trim.
This is a design choice, not a gap. A state alert is honest about what is true right now. A transition alert is honest about a moment. Each has uses; the one that survived into this script is the state alert because multi-timeframe transitions are noisy under repaint and on mixed cadences, and because a reader who wants a transition is in a better position to define "what counts as one" than a one-size-fits-all script is. Does a two-bar retracement that re-crosses count as two transitions or one? On a chart-bar close with On Bar Close? off, does a slot flipping and un-flipping inside its live slot-timeframe bar count? Those questions have different answers per workflow, and the honest move is to leave them to the reader rather than pretend one answer fits everyone.
Bar-close gating
Every alert condition is gated by barstate.isconfirmed. In plain language: the condition is only evaluated — and can only fire — on the close of a chart bar. Intra-bar conditions are not evaluated. This is true for every alert in all three groups.
Two subtleties worth pinning down.
The gate lives on the chart bar, not the slot's configured-timeframe bar. A 1-minute chart with a 60-minute slot still evaluates alerts at the close of each 1-minute bar. The evidence behind the alert (the slot's fast-versus-signal state) is sourced from the slot's
request.securitycontext and its value at evaluation time depends onOn Bar Close?.On Bar Close? = offdoes not make alerts intra-bar. With the switch off, the slot's evidence can keep changing while the chart bar is open, but the alert gate still waits for that chart bar to close before evaluating. The alert will fire based on whatever the slot's evidence was at that chart-bar close, which may itself be mid-bar on the slot's configured timeframe when that timeframe is above the chart.
If you are running On Bar Close? off, be aware that the alert is firing on a chart-bar close using slot evidence that may revise before the slot's current bar closes. That is a meaningful asymmetry. The honest framing is: the alert fires on confirmed chart bars, but the underlying evidence can be provisional. MTF and Repainting explores that asymmetry in detail.
Per-slot alerts (six conditions)
Two conditions per slot — one when the slot is in its bullish state (its fast above its own signal), one when bearish. These fire on the confirmed close of the chart bar and describe the slot's ongoing posture.
Use them when:
You want chart-bar-close notification that a specific slot is holding a direction.
You are building an external workflow that chains slot states with other evidence.
You want a higher-timeframe slot's read without sitting on the chart to watch for it.
Do not use them when:
You need a notification on the flip. These fire on the state, not the flip. You will get many notifications during an uninterrupted bullish stretch.
You are hoping that "MACD 03 Is Bullish" alone is enough to act. A single slot's state is a single piece of evidence. The pack treats even the blend of all three as headline, not conclusion.
Blend alerts (two conditions)
Two conditions on the blended fast-versus-slow relationship — bullish (fast above slow) and bearish (fast below slow). Evaluated on confirmed chart bars.
A crucial behavior to name: if Enable Master Smoothing is on, these alerts fire on the smoothed blend, not the raw blend. That means the alert is evaluating a different series than the unsmoothed blend. Most of the time the trade is calmer visuals for later turns, and short-lived raw states may disappear entirely. If you have enabled master smoothing in the name of getting "cleaner" alerts, you should know that cleanliness can cost timing and evidence. See the tripwires section of Settings.
A second behavior worth naming: when the blend is na (every enabled slot is at weight zero, or every contributing slot is still warming up), neither blend alert fires. This is not a silent failure — it is the only honest thing to do when there is no blend to evaluate.
Alignment alerts (two conditions) — and the trap
Two conditions — All MACD Slots Bullish and All MACD Slots Bearish. Both fire when every enabled slot with a non-na reading agrees on direction. This is the pane's most seductive alert group, and the one that carries the highest risk of over-trust.
Two specific behaviors the user has to internalize.
Alignment is a state across your configuration
Alignment fires when every enabled slot agrees. "Every enabled slot" includes weight-zero slots. A slot with weight 0 still counts toward alignment as long as it is enabled and has a non-na value. So the observer-slot pattern (enable a slot, keep its plot visible, set its weight to zero for blend exclusion) does not exclude that slot from the alignment tally. If you want a slot out of both the blend and the alignment count, disable the slot.
Alignment is not breadth
If your three slots share the same source, the same length pair, and the same MA family, differing only in timeframe, then alignment firing is closer to one measurement agreeing with itself across three cadences than to three independent observations reaching the same conclusion. During any trending session on a liquid instrument, that kind of alignment will fire for long stretches and fire reliably. The reliability is a feature of the configuration, not evidence for the read.
With three slots in Base, each slot carries a third of the alignment signal and a third of the blend. The alignment trap costs more per slot here than in a ten-slot trim, not less. Limitations and Trust Boundaries leads with this specific topic because the damage pattern is the highest in the pack.
The cure is differentiation. Three slots that genuinely represent three different stories — different length pairs, possibly different MA families, possibly different sources — will align only when three different readings actually agree, which is a lot more informative than three copies of the same reading agreeing.
What this indicator does not alert on
Stating these explicitly because each one is the kind of thing readers expect and do not find, and the silence can feel like a gap rather than a decision.
No crossover or crossunder alerts. No "MACD 01 Just Crossed Bullish" condition. Transitions live in your own alert wiring.
No histogram alerts. The four-state column color — bullish accelerating, bullish decelerating, bearish accelerating, bearish decelerating — is a reading surface, not an alert source. There is no "histogram turned bright red" condition.
No overbought or oversold alerts. The 70 and 30 reference lines are visual zones. No alert fires when the blend or a slot crosses them. If you want a threshold alert, TradingView's generic "price crosses" alert works against any plotted series and can be wired manually.
No divergence alerts. No alerts on divergence between the blend and its slots, or between the fast and the slow within a slot, or between price and the pane.
No warm-up alerts. The indicator does not notify you when every slot has finished warming up. You will see that directly on the pane as lines form.
If you feel a gap here, the next step is usually a manually-wired TradingView alert on the plotted series, not a request for the indicator to grow a new alert surface.
Alert wiring notes
A few practical things worth saying out loud.
When you create an alert in TradingView against this indicator, pick "Once per bar close" rather than "Only once" as the default — it matches the bar-close gating inside the script. "Only once" can hide the fact that a state is holding across many bars, which sometimes reads as a flip when it was nothing of the sort.
For the alignment and blend alerts, decide in advance how you want repeated firings handled. If you would rather not have ten notifications across ten consecutive bullish bars, wire an external condition-change wrapper (either TradingView's built-in "alert on condition change" against the plotted series, or a downstream rule in your own system) instead of alerting on the state directly.
Check
Enable Master Smoothingbefore wiring blend alerts, and write down which it was set to at wiring time. A blend alert on the smoothed series and a blend alert on the unsmoothed series are different notifications; a reader who forgets the switch was on will later compare alert timings and wonder why they no longer line up.If alignment alerts fire with suspicious reliability — for example, several times a session on a calm instrument — inspect your slot configuration before you touch anything else. Three near-identical slots will align on trend persistence; the cure is differentiation, not a higher alignment threshold.
Name your alert conditions with the configuration attached. "MACD 03 Bull, 60m EMA 48/104/36, OBC on" is a long alert name, but it is the alert name that still tells you what fired in three weeks.
Where to go next
Why alignment across similar slots is not evidence, and why pinning is not intensity — Limitations and Trust Boundaries.
Named configurations that differentiate the slots properly — Workflows.
The repaint switch, the slot-timeframe rule, and the alert-gate asymmetry — MTF and Repainting.
When an alert will not fire and you expected it to — Troubleshooting.