Alerts

Read this page before you wire the first alert. The alerts in Axiom Stoch Osc CTX are deliberate in a way that will surprise readers who are used to common retail indicators, and wiring them without reading the rules here is the fastest way to fill your inbox with signals that do not say what you think they say.

The section headers below are short on purpose. The payload of this page is two framings: state-versus-cross, and enabled-versus-weighted. Those two framings decide whether the alerts will be useful to you or a source of unnecessary noise.

State alerts versus cross alerts — the single most important distinction

Every alert condition in this script is a state alert. That means:

• The condition is true whenever a given state (bullish or bearish) is currently true on a confirmed chart bar.

• The alert fires once per confirmed chart bar where the state is true. It fires again on the next confirmed bar if the state is still true.

• It does not wait for the state to transition. It does not fire only when the K crosses the D; it fires every time a confirmed bar closes with the K already above (or below) the D.

A cross alert, by contrast, fires only on the bar where a transition occurs — once per transition. The difference in notification volume is not small. A slot that is bullish for twelve consecutive chart bars will fire its bullish alert twelve times. A cross alert, for the same state history, would have fired once, on the bar of the crossover. On a 1-minute chart of a trendier instrument, a state alert on a 60-minute slot can fire hundreds of times a day while the equivalent cross alert fires once or twice.

The distinction is deliberate. A state alert tells you "right now, the condition is true." A cross alert tells you "right now, the condition just became true." For a reader using alerts as presence-of-state indicators (for example, to confirm the blended pair is currently lime before taking a discretionary entry), the state alert is the correct shape. For a reader using alerts as transition notifications (fire once when the state flips, then stay quiet), the state alert needs downstream help.

There is no cross-style alert condition in the script. If you need cross-style behavior, you have two options:

1. Build it in your alerting service downstream. Most services can suppress duplicate alerts within a time window; a five-minute window on a state alert converts it to an approximate cross alert with some edge-case noise.

2. Build a helper script for the specific series you can actually access. The blended K and blended D are plotted, so blended cross alerts can be built from those. Per-slot K is plotted, but per-slot D is internal; a per-slot K/D cross helper has to reproduce that slot's D calculation from the same settings instead of reading a plotted D series.

Inventing a cross alert here where the script does not expose one would require either duplicating plotted values inside this indicator or hiding the state-vs-cross decision from the reader, and neither is a trade this pack is willing to make. Naming the absence is the more useful move.

Enabled slots versus weighted slots — the second important distinction

The alignment alerts (All Stoch Slots Bullish, All Stoch Slots Bearish) count every enabled slot, regardless of weight.

That includes slots whose Blended Weight is zero. A slot with Enable on and Blended Weight of 0 contributes nothing to the blended pair but does contribute to the alignment count. If a reader expects "alignment" to mean "the slots that matter to the blend all agree," the count will be confusing every time a zero-weight slot breaks the tie.

The right mental model is this: Enable is the question "should this slot be in the count at all?"; Blended Weight is the question "how much should this slot steer the composite?". They are separate questions. The alignment alert uses the first. The blend uses both.

If you want a slot not to be in the alignment count, disable it. Setting the weight to zero is the wrong answer for that particular question.

Every alert condition in the script, listed honestly

There are twenty-four alertcondition() definitions, in three families. All twenty-four are gated on barstate.isconfirmed at the chart-bar level. None of them will fire during an in-progress chart bar; they all evaluate only on confirmed chart bar closes.

Per-slot alerts — 20 total, 2 per slot

For each of the ten slots, two alert conditions:

Blended-pair alerts — 2 total

Alignment alerts — 2 total

That is the complete list. Twenty per-slot, two blended, two alignment. Twenty-four in total.

Equality is neutral in the alert layer. K == D is neither bullish nor bearish, even though some visuals draw equality in the faded or red state because their color rule is "not above."

Alerts that do not exist, and will not be invented

Every absence below is deliberate. The script does not expose these alerts, and documenting them as if it did would teach a mental model the product cannot back up.

• No overbought alert. The 80 guide is a visual landmark. There is no alertcondition() wired to the blended K or any slot K crossing 80.

• No oversold alert. Same as above for the 20 guide.

• No midline cross alert. The 50 line is a neutral landmark. No alert fires on any line crossing 50 in either direction.

• No cross-style alerts. No alert fires specifically on the bar where a K crosses its D. The state alerts fire every bar the state is true; they do not distinguish the crossover bar from the steady-state bars.

• No divergence alerts. The script does not evaluate divergence against price.

• No weighted-alignment alert. There is no alert that checks "every slot with non-zero weight agrees." Alignment counts every enabled slot, weight or not.

If any of those is on your alert wish list, you need to build it externally. The plotted per-slot K values and the plotted blended pair are available to downstream scripts on the chart; the per-slot D values are not plotted separately.

What the firing volume will look like in practice

A useful calibration before you enable anything:

• A single per-slot state alert will fire on every confirmed chart bar the state holds. On a 1-minute chart with a 5-minute slot trending one direction, that can mean dozens of fires in an hour. The alerts are working as intended.

• The blended-pair alerts will fire on every confirmed chart bar the blended K is above or below the blended D. Equality is quiet. State transitions on the blended pair tend to be less frequent than on any single slot — the averaging tends to hold state — but the alert still fires on every confirmed bar of that state.

• The alignment alerts fire less frequently in proportion to how many slots you have enabled and how divergent they tend to be. On a multi-timeframe stack of one symbol at shipped defaults, alignment is common during clean directional moves and rare during chop. On a widely divergent roster (for example, a mix of 1m and 4h slots on the same symbol), alignment happens during strong multi-timeframe moves and is otherwise absent.

A single enabled slot makes the alignment condition trivially equal to that slot's own bullish/bearish state. If you enable only one slot, All Stoch Slots Bullish fires whenever that one slot is bullish. This is correct behavior, not a bug. If you want alignment to mean "more than one slot agrees," you need to enable more than one slot.

Useful alerting patterns

The following patterns are deliberate ways to use the alert surface without being drowned by it.

The alert-only slot

Enable a slot, turn Hide Plot on, and set Blended Weight to zero. The slot computes in full, fires its own state alerts, and contributes nothing to the pane or the blend. This is clean for watching a higher-timeframe state without cluttering the pane — for example, a 4-hour slot on the chart symbol whose state you want to know about but whose K line you do not want to see.

Note: because the slot is enabled, it still counts toward the alignment alerts. If you have multiple alert-only slots active and use alignment, the alignment behavior will reflect those slots' states. That is often the point.

The blended-pair watch

Set up one alert: Blended Stoch Is Bullish or Blended Stoch Is Bearish, depending on which direction matters to you. Combine it in your alerting service with a suppression window ("do not re-fire within N minutes"). You now have a coarse notification when your composite shifts direction, without needing to inspect per-slot state.

This pattern makes Blended Stoch Is Bullish effectively cross-style, at the cost of needing downstream suppression logic.

The multi-slot alignment trigger

Enable exactly the slots whose agreement you care about — no spectators, no zero-weight slots for visual reference — and wire All Stoch Slots Bullish (or Bearish). The alert fires on every confirmed bar where all enabled slots agree. Combine with downstream suppression if you want a single notification per alignment episode.

If you want alignment to be weighted-only, you have to adjust the roster, not the alert. Disable the slots that should not count. Zero-weighting them is not enough.

The per-slot watch on a higher timeframe

Enable a slot at a higher timeframe (say, 4h), keep On Bar Close? on, and set an alert for its state. Because the slot returns the previous confirmed 4-hour bar's K and D, the alert will not re-fire within a 4-hour bar due to the slot's own movement — the slot's value is stable throughout a 4-hour interval. The alert still evaluates on every confirmed chart bar, so if your chart is on 5-minute, the alert fires every five minutes while the 4-hour slot's confirmed state holds. This is the product of two timing layers (chart bars and higher-timeframe bars) and the manual will not hide the interaction.

Alert messages — what the script sends by default

Each of the 24 conditions ships with a default message that includes the slot or blended name, the state, and the {{ticker}} and {{interval}} placeholders. If you add an alert in TradingView using the default message, the notification identifies the symbol and chart interval that fired it. You can override the message in the alert dialog as usual.

The pack does not recommend specific custom messages. If you use a webhook to forward alerts to another system, write the message to match what that system needs to do with it.

Common confusions, named on purpose

• "The alert is firing every bar. Is it broken?" No. The alerts are state alerts, not cross alerts. See Troubleshooting for the full framing.

• "The alignment alert fired with only one slot enabled. Is that right?" Yes. A single enabled slot makes the condition trivially equal to that slot's own state. If you want alignment to mean "multiple slots agree," you need multiple enabled slots.

• "I set a slot's weight to zero and it still fired its alert." Correct. The weight only affects the blend. Enable controls whether the slot computes and alerts. The two switches are independent.

• "I don't see an alert for 80 or 20 crossing." There isn't one. The guides are visual. If you need that alert, build it externally on the plotted K values.

• "Why is the blended alert firing when the blended line is flat at 50?" A line at 50 is not ambiguous in this script; the condition is strictly K versus D, not K versus any level. If the blended K is one tick above the blended D at 50, the bullish condition is true.

A pre-flight checklist before you enable any alert

Alerts are cheap to wire and expensive to uncalibrate from once you have trained yourself to react to them. Run this checklist on every alert before you leave the dialog.

1. State the question the alert is answering. In one sentence. "I want to know when my 1-hour slot flips bullish so I can check the full pane." If you cannot state it, the alert is noise waiting to be labeled.

2. Match the alert's behavior to the question. Every alert in this script is a state alert. If the question is really "when did it flip," a state alert will fire every confirmed bar the state holds — dozens of times per flip on an active chart. Add downstream suppression, or build a cross-style alert externally where the needed series are available, before accepting the state-alert volume as the answer.

3. Audit the enabled roster for alignment alerts. All Stoch Slots Bullish and Bearish count every enabled slot, including zero-weight slots. If you have a slot enabled for visual reference at weight zero, disable it before wiring alignment — or accept that alignment requires that slot to agree too.

4. Consider how this alert behaves during a regime change. State alerts on the blended pair stay silent through long master-smoothed state holds. Per-slot alerts can fire many times during a choppy transition before the state settles. Neither is a bug; both are wiring decisions you should make consciously.

5. Decide on suppression before the first notification. Downstream alerting services can dedupe within time windows. Set that window before you enable the alert, not after the first inbox flood. Going from "too many alerts" back to "the right number of alerts" is more expensive than going the other direction, because you have to rebuild your gut calibration of what the alert means.

6. Wire it as a test for a trading day before committing to it. Watch the volume, note the fires that correspond to readings you actually wanted, and note the ones that did not. Then decide whether to keep it as-is, suppress differently, or remove it.

An alert that survives the checklist is an alert you know how to read. An alert that does not survive it is an alert that will train you to either ignore it or act on it reflexively, and neither of those is a posture this pack supports.