Alerts

Read this page before you create any alerts on this indicator. Most of the surprise people have with the alert behavior here comes from one assumption that does not hold: that alerts will only fire when something changed.

That is not how the alerts in this script work. They fire on the confirmed bar whenever the named state holds. They are state alerts, not cross alerts. The implication is large enough that the rest of this page is mostly about it.

State alerts versus cross alerts

A cross alert fires once, on the bar a condition transitions — for example, on the bar an RSI line first goes above its signal, and not again until it drops below and crosses up again.

A state alert fires every time a confirmed bar closes with the condition true — for example, on every confirmed bar where the RSI is currently above its signal, regardless of whether it just crossed.

Every alert this script exposes is a state alert, gated on confirmed bars. If RSI 01 is bullish for thirty consecutive confirmed bars, the RSI 01 Is Bullish alert fires thirty times.

Why the design chose state over cross, in case the choice seems arbitrary: a cross is an event that happens once, and if your automation misses it — because TradingView hiccuped, because your webhook was rate-limited, because you reloaded the chart at the wrong moment — the state itself is gone and you have no way to recover it on the next bar. A state alert fires again on the next confirmed bar, and the next, as long as the condition holds. It is noisier on purpose. The tradeoff is that a reader who expected cross semantics will get a flood of notifications they did not expect. Once you know the design, you build around it; the first discovery is usually loud.

Why this matters before you wire anything:

• If you expect cross behavior and get state behavior, your inbox or webhook destination will receive many more notifications than you planned for.

• If you are routing alerts into automation or a messaging service with rate limits, your downstream system will be the one to notice the count, not you.

• If you are using "any alert" routing across many alert conditions, the volume scales with the number of slots you enabled and the persistence of the states. Enable ten slots, wire both bullish and bearish on each, enable both alignment alerts and both blend alerts, and you are looking at twenty-four state alerts firing on every confirmed bar where something is true — which is nearly every bar.

There is no flag inside the script to flip these to edge-triggered behavior. If you need cross behavior, you build it externally — for example, with TradingView's alert frequency setting set to "Once Per Bar" combined with conditions you compose yourself in the alert dialog, or by routing through automation that suppresses repeats.

What conditions are exposed

The script exposes twenty-four alertcondition slots. They group into three families.

Per-slot state — twenty alerts

For each of the ten slots, two conditions:

• RSI NN Is Bullish — fires on a confirmed bar where slot NN's RSI is above slot NN's signal.

• RSI NN Is Bearish — fires on a confirmed bar where slot NN's RSI is below slot NN's signal.

Notes:

• A disabled slot does not fire either condition. Enabling and then hiding a slot keeps the conditions live; only disabling silences them.

• A weight-zero slot still fires its conditions if it is enabled. Weight controls the blend, not whether the slot exists.

• The two conditions are not mutually exclusive across bars; they are mutually exclusive on any single confirmed bar (the slot is either bullish or bearish on that bar's close, not both).

Blended state — two alerts

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

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

Notes:

• These conditions evaluate on the same composite the lime/red plot is showing. If the blend is NA (because every weight is zero or every contributing slot returned NA), neither condition fires.

• Master smoothing, if enabled, is applied before the comparison. A long master length will keep these conditions firing on one side longer than the underlying slots would suggest. That behavior matches what you see on the pane; it is not a bug, but it is worth knowing when you wire automation.

Alignment — two alerts

• All RSI Slots Bullish — fires on a confirmed bar where every enabled slot with an available RSI value is bullish on that bar.

• All RSI Slots Bearish — fires on a confirmed bar where every enabled slot with an available RSI value is bearish on that bar.

These conditions deserve their own warning. They have two sharp edges that cause repeated misreads.

Sharp edge 1: alignment counts enabled slots, regardless of weight. A slot you enabled but set to weight zero — perhaps because you wanted it as context only — still counts in the alignment check once its RSI value exists. If you set up a "context only" slot expecting it to stay out of the alignment math, the alignment alerts will not match your mental model. Either disable the slot when you do not want it counted, or rebuild your expectation.

Sharp edge 2: alignment is a count of enabled slots, not "many slots." If only one slot is enabled and its RSI value is available, the alignment alerts fire whenever that single slot is in the named state. "All Bullish" with one available enabled slot is just "the single slot is bullish on the confirmed bar." If you are using alignment as a filter for high-conviction conditions, your enabled-slot set is doing the heavy lifting — not the alignment check.

A practical implication: if you want alignment to mean "agreement across the slots that steer the blend," you should curate the enabled-slot set to only those slots. Use disable, not weight zero, to remove a slot from alignment.

What the script does not alert on

It is worth being explicit about absence, so you do not search the dialog for conditions that are not there.

• No alerts on overbought, oversold, or midline crosses. The 70/30/50 references are visual guides only. The script does not expose RSI Crosses Overbought, Blended Above 50, or anything similar. If you want those, build them outside the script using TradingView's plot-based alert dialog, with the blended RSI or a slot's RSI as the source.

• No edge-triggered cross alerts. As noted above, every condition this script exposes is state.

• No alerts that fire intra-bar. All conditions are gated on barstate.isconfirmed. They evaluate on bar close, not during bar formation.

• No alerts on the invisible counts. The Active Bullish Count and Active Bearish Count plots are visible to your own custom alerts via TradingView's plot-based alert dialog, but the script does not pre-build alert conditions on them.

If a condition you want is not on this list, the answer is to compose it yourself in the alert dialog rather than to look harder inside this indicator.

Verifying the behavior on your own chart

This is the verification routine that lets you trust what your alerts will do.

1. Set up the indicator with one slot enabled (slot 01) and the other slots disabled.

2. Create an alert on RSI 01 Is Bullish with Once Per Bar Close selected as the alert frequency.

3. Wait for a chart bar to close while slot 01 is bullish. The alert fires.

4. Wait for the next chart bar to close, with slot 01 still bullish. The alert fires again.

5. Wait for slot 01 to flip bearish, and for the next chart bar to close. The alert does not fire.

6. Re-enable slot 02. Set its weight to zero. Create an alert on All RSI Slots Bullish.

7. Watch what happens when slot 01 is bullish but slot 02 is bearish: the alert does not fire, even though the only "weighted" slot is bullish. Confirmation that alignment counts enabled slots with available RSI values, including weight-zero ones.

That ten-minute check is worth the time. It reveals both the state-alert behavior and the alignment caveat in concrete form, which is harder to forget than reading them on this page.

Practical posture for wiring alerts

A short set of habits that keep the alert layer honest in production.

• Decide what you want the alert to mean before you create it. A RSI 01 Is Bullish alert is not "RSI 01 just turned bullish." It is "RSI 01 is currently bullish on a confirmed bar." Phrase your inbox label accordingly so that future-you remembers. If the label in your inbox does not match the semantics of the alert, you will misread it in a hurry six weeks from now.

• Use TradingView's "Once Per Bar Close" frequency setting when you want the alert to evaluate strictly on confirmed bars. This is consistent with the script's gating and avoids extra evaluations during bar formation.

• Disable, do not zero-weight, slots you do not want in alignment. If you are wiring All RSI Slots Bullish, your enabled-slot set is the meaning of "all." This is the single most common alignment-alert mistake, and it is quiet — the alert simply stops firing in setups where you expected it to, because the slot you meant to silence is still counted.

• Do not chain alerts as if they were entry conditions. Even if every alert this script exposes was firing simultaneously, that would not be a buy. The blend is a weighted average you designed, the alignment is a count of slots you enabled, and neither is independent of your configuration. Entries are decisions; alerts are notifications about states.

• Verify cross-asset alerts with the cross-asset slot's session in mind. A slot on a foreign symbol's session can stay in the same state for the entire chart symbol's day if the foreign market is closed. The state alerts will keep firing on every confirmed chart bar during that period — the foreign state has not changed, and the alert is honestly evaluating what it was told to evaluate.

• Review your alert volume after a week. Count what fired, what fired more than expected, and what did not fire when you thought it would. The first week's volume tells you whether your mental model of the alert layer matches the script's behavior. Most readers find at least one surprise in that review; catching it a week in is cheap, catching it after a month of muted attention is not.

Where to go next

• For the underlying timing — what "confirmed bar" means at the chart level versus the slot level — go to MTF and Repainting.

• For the over-trust traps the alignment alerts can produce, go to Limitations and Trust Boundaries.

• For symptom-to-cause guidance when an alert fires more (or less) than you expected, go to Troubleshooting.