Alerts

The Base trim ships ten alert conditions. They are observations about state on confirmed chart bars, and they are wired as state-based conditions rather than edge-triggered events. This page enumerates them by group, names what each one confirms, names what it does not confirm, and is explicit about the alerts the trim deliberately does not ship. Most of the first-time surprise around these alerts comes from expecting edge-triggered behavior and not getting it; the rest comes from reading the alignment pair as a stronger claim than it actually makes.

The frame — state on a confirmed chart bar

Every alert on this tool is gated on barstate.isconfirmed. That gate evaluates to true once per chart bar, on the close of that chart bar. An alert condition checks whether its named state holds on that confirmed chart bar; if it does, the alert fires.

Two properties follow from this wiring:

• State, not transition. The alerts do not track "just turned bullish" or "just crossed." They track "is currently bullish" or "is currently bearish." If a slot holds its bullish state across many chart bars, the slot's bullish alert will re-fire on every confirmed chart bar where the state holds. The tool ships no edge-triggered condition. Blend RSI and blend signal are plotted, so a user can build some blend-level crossing alerts in TradingView. Per-slot signal lines are not plotted, so per-slot RSI-vs-signal transitions are not available as simple plotted-line alerts from this indicator.

• Chart-bar cadence, not slot-bar cadence. The confirmation gate fires on chart-bar closes. A slot on a 60m timeframe with a 1m chart evaluates on every confirmed 1m chart bar. If the slot is bullish, the slot's bullish alert can fire sixty times over a single 60m bar. See MTF and Repainting for the full asymmetry.

If your alerting expectation is "fire once per event," the tool does not meet it natively. The practical options are: set the alert to Once Per Bar Close and accept that it re-fires on every confirmed chart bar while the state holds; set it to Only Once in TradingView and accept that it will never fire again in that alert's lifetime; or route through an external dedup layer (webhook plus downstream logic) that drops repeated firings. The tool's own conditions are intentionally state-based, so the dedup logic has to live somewhere else when you need it.

The ten conditions

Per-slot state alerts (six)

• RSI 01 Is Bullish — slot 01's smoothed RSI is above its smoothed signal line on a confirmed chart bar.

• RSI 01 Is Bearish — slot 01's smoothed RSI is below its smoothed signal line on a confirmed chart bar.

• RSI 02 Is Bullish and RSI 02 Is Bearish — the same pair, for slot 02.

• RSI 03 Is Bullish and RSI 03 Is Bearish — the same pair, for slot 03.

What these alerts confirm: the slot's smoothed RSI has the named relationship to the slot's smoothed signal on the current confirmed chart bar. That is the same comparison the slot's color encodes. A bullish-state alert is the slot's color-aware directional read going through a notification surface.

What they do not confirm: anything about the slot's position relative to the midline or the 30/70 reference zones, anything about a crossing event, anything about the intensity of the lean, anything about the blend's state.

Alert interaction with Hide Plot: hiding a slot's plot does not disable the slot or its alerts. A slot with Hide Plot on still runs its RSI-and-smoothing pipeline, still evaluates its bullish/bearish state, and still fires its state alerts. If you have an alert wired on a slot whose plot you hid, the alert will continue firing on the slot's state.

Alert interaction with weight: a slot's blend weight has no effect on the per-slot alerts. A weight-zero slot still fires its own bullish and bearish state alerts as long as it is enabled. Zero weight is a blend-exclusion knob, not an alert-disable knob.

Blend state alerts (two)

• Blended RSI Is Bullish — the blended RSI is above the blended signal on a confirmed chart bar.

• Blended RSI Is Bearish — the blended RSI is below the blended signal on a confirmed chart bar.

What these alerts confirm: the weighted-average blend has the named relationship between its RSI and signal lines on the current confirmed chart bar. That is the same comparison the blend color encodes.

What they do not confirm: breadth across slots, agreement among slots, or anything about the blend crossing 50 or the reference lines. A blend alert fires on the blend's own internal RSI-vs-signal state, nothing else.

Alert interaction with the display toggle: Plot Blended RSI/Signal = false hides the blend's visuals. It does not stop the blend from computing or the blend alerts from evaluating. A reader who hides the blend for visual reasons and then wonders why a blend alert fired is encountering the correct and intended separation between display and logic.

Alignment alerts (two)

• All RSI Slots Bullish — every enabled slot whose RSI is non-na is above its own signal on a confirmed chart bar.

• All RSI Slots Bearish — every enabled slot whose RSI is non-na is below its own signal on a confirmed chart bar.

What these alerts confirm: the named state holds across all enabled slots that have had enough bars to produce a non-na RSI. The alignment tally counts every enabled slot equally regardless of weight. A weight-zero slot that is still enabled still counts toward alignment.

What they do not confirm: agreement among independent observations. The alignment alerts compare three slots running on three timeframes of the same chart instrument. Three timeframes of one symbol are not three independent opinions — the same move on the fast slot cascades into the slower slots by construction. Alignment is a cadence-coverage read, not a consensus read. Treat it as a reason to look, not as a reason to commit.

What they also do not confirm: anything about a transition. There is no "All Slots Just Turned Bullish" condition. An alignment alert fires on every chart bar where the alignment state holds. On a trending instrument with three identical slots differing only by timeframe, alignment can hold for hours, and the alignment alert will re-fire on every confirmed chart bar in that window.

The register flags this caveat as one of the two most costly misreads on the trim. Limitations and Trust Boundaries carries the full treatment. It is planted here because the alignment alerts are the most tempting part of the alert surface, and the correction has to arrive in the same reading flow as the alert itself — a reader who wires these alerts, receives them during a live session, and only later visits the limitations page will have already built a reading habit on a read the limitations page is trying to weaken. If you take one thing from this section, take this: an alignment alert is a reason to look at the slots, not a reason to conclude from them.

What is deliberately not on this trim

The alerts below are not omissions; they are design decisions. If you come looking for them and cannot find them, you have found the intentional scope of this trim.

• No crossover alerts. There is no RSI 01 Just Crossed Up, Blended RSI Just Crossed Signal, RSI 03 Just Crossed 50, or anything of that shape. All state, no transitions. TradingView can use plotted series for some custom alert work, but the per-slot signal lines are hidden, so the per-slot RSI-vs-signal crosses are not exposed as plotted-line pairs.

• No threshold alerts on the reference zones. Nothing in this tool fires when a slot RSI or the blended RSI crosses 30 or 70 or touches 0 or 100. The 30 and 70 lines are visual references; the tool has no internal logic that treats them as triggers.

• No divergence alerts. There is no native divergence-detection between price and RSI, between slot RSI and slot signal beyond the simple above/below test, or between slots. If you want divergence alerting, that is a separate instrument — you wire it outside this tool.

• No alignment-transition alerts. There is no "All Slots Just Turned Bullish." The alignment alerts fire on state persistence, not on the moment state changed.

• No regime-change alerts on the blend. There is no "Blend Just Flipped" condition either.

Naming these absences plainly is a design choice. A reader who is not told what is not there will spend time hunting for alerts that do not exist.

Wiring alerts in TradingView

The conditions defined by this tool are exposed through TradingView's standard alert-creation dialog. Select the indicator, pick the condition from the dropdown, and choose the alert frequency — Once Per Bar Close lines up with the tool's own gate (one notification per confirmed chart bar), while Once Per Bar tends to fire early on developing bars.

Message substitutions like {{ticker}} and {{interval}} are pre-filled on the default alert messages the tool provides, so the notification will name the instrument and the chart's timeframe without you having to wire those in manually. If you need routing (webhook, email, push), that is set on TradingView's side, not inside the tool.

One practical caution: if you set a per-slot alert to Once Per Bar on a live-mode run (On Bar Close? = false), the alert can fire on a chart bar whose slot state was produced against a live, still-revising higher-timeframe bar. That does not mean the alert is wrong — it reports the slot state at the moment of the chart-bar close — but you should know what the value it is firing against was computed from. For the confirmed-only read, keep the tool's own On Bar Close? = true and set the alert frequency to Once Per Bar Close.

Where to go next

• The reading order the alerts reflect — Visuals and Logic.

• The On Bar Close? tradeoff in full — MTF and Repainting.

• Why the alignment alerts deserve caution, organized by damage potential — Limitations and Trust Boundaries.

• Alerts firing more than expected or not at all — Troubleshooting.