Alerts

This page is for the reader who is wiring this indicator into an alert-driven workflow — a systematic operator, or a discretionary trader who wants a notification to pull them back to the chart. Sixteen alert conditions exist. Each has a specific firing semantics. Some are state alerts that repeat on every bar the condition holds; two are divergence alerts that fire once on a confirmation bar; and two are alignment alerts with an upstream behaviour you need to know about before you wire them.

Read this page before you save any alert. The cost of wiring an alert that fires differently than you think it does is that you build a system on top of an alert that is quietly wrong, and you only find out about the wrongness when a state alert spams your webhook at bar close every bar for an hour, or when an alignment alert never fires at all and you assume the market is simply not aligning. Both are real outcomes reported by real readers. The rows below exist to keep them from being your outcomes.

The alert surface at a glance

Sixteen alertcondition entries sit at the bottom of the script. They group as:

Four facts bind all sixteen before any row matters:

• All alerts are gated by barstate.isconfirmed. A forming bar cannot fire. The alerts wait for the bar to close.

• A disabled slot's alert cannot fire. The condition for per-slot alerts includes the slot's Enable toggle, so turning a slot off silences its alerts.

• The per-slot bullish/bearish alerts and the blend bullish/bearish alerts are state alerts, not cross events. They repeat every confirmed bar the state holds.

• The divergence alerts fire on the confirmation bar. Plot On Pivot does not back-shift the alert; it only back-shifts the drawing.

State alerts versus cross events

State alerts and cross events are different creatures, and the difference matters for wiring.

A state alert fires every confirmed bar the condition is true. If the blend K has been above the blend D for the last thirty bars, you get thirty fires — one per bar close — unless you throttle them externally.

A cross event would fire once, the bar where the condition flipped from false to true. This indicator does not expose cross events as dedicated alerts.

The practical consequence:

• If you want a cross-event alert, wire an external one-shot mechanism on top of the state alert (TradingView's "Only Once" frequency, your webhook server's deduplication, or a bar-to-bar memory on your side).

• If you want a sustained notification — "tell me the blend is leaning bullish right now" — the state alert is what you want, and you set TradingView's frequency to "Once Per Bar Close" to throttle it to one per confirmed bar.

Do not fight the semantic the indicator gives you. Name the semantic, then pick the right TradingView frequency and the right external logic around it.

The ten per-slot alerts

One bullish and one bearish alert per slot, across all five slots. Each fires on confirmed bars when the slot's Enable is true and the slot's K and D are on the named side.

• Stoch 01 Is Bullish through Stoch 05 Is Bullish: K above D on that slot, on confirmed bars, slot enabled.

• Stoch 01 Is Bearish through Stoch 05 Is Bearish: K below D on that slot, on confirmed bars, slot enabled.

Wiring tips

• Throttle with "Once Per Bar Close." Pick this in the TradingView alert dialog so the alert fires at most once per confirmed bar. The script gate already prevents forming-bar fires; the frequency setting controls how noisy a continuing state becomes across confirmed bars.

• Send the slot identity into the message. The default messages use {{ticker}} and {{interval}}. If you run multiple slots at multiple timeframes, include the slot number in the message body so your downstream system knows which slot triggered — for example, "Slot 03 bullish on {{ticker}} {{interval}}".

• Do not expect a cross event. A per-slot bullish alert fires the first confirmed bar K is above D and every confirmed bar after that while the state holds. Cross detection is yours to build.

Common misread

If you want "Slot 03 just crossed bullish, alert me once," the per-slot bullish alert as-is will give you that first fire — but it will also keep firing every subsequent confirmed bar while the state holds. That is not a bug; that is the contract. Build your cross logic externally, or use TradingView's "Only Once" frequency if your workflow genuinely wants one fire per chart session.

The two blend alerts

• Blended Stoch Is Bullish: blend K above blend D on confirmed bars.

• Blended Stoch Is Bearish: blend K below blend D on confirmed bars.

Same state semantics as the per-slot alerts. Same throttling needs.

The blend alerts pay attention to master smoothing. When Enable Smoothing is on, the blend K and blend D are both smoothed, and the K-vs-D comparison the alert reads is the comparison after smoothing. Smoothing adds lag. The alert fires slightly later than it would on the unsmoothed blend. If you enable master smoothing, do not be surprised when the blend alert is a beat late compared to the pane you watch.

The two alignment alerts — with a disclosure

All Stoch Slots Bullish and All Stoch Slots Bearish are designed to fire when every enabled slot is on the named side. On a three-slot default configuration with all three slots bullish, the bullish alignment alert fires on the confirmed bar. On a two-slot configuration with slots 01 and 02 enabled and both bullish, it fires. On a four-slot configuration with slots 01–04 enabled and all four bullish, it fires.

It does not fire on any configuration that has slot 05 enabled.

What is actually happening

In the current alignment-counter block, the slot-05 branch increments the activeSlotCount variable six times instead of once. The bullCount and bearCount variables still only increment once per bullish or bearish slot, including for slot 05. The alignment check is an equality: bullCount == activeSlotCount for the bullish alert, bearCount == activeSlotCount for the bearish.

Because activeSlotCount is too high whenever slot 05 is enabled, bullCount and bearCount cannot reach equality with it, and the equality check never evaluates true. The result: neither alignment alert fires on any bar while slot 05 is enabled.

What to do about it

The manual is not where the code gets fixed. The manual is where the code gets told the truth about, so you do not build a system on top of an alert that will not fire in your configuration. Three responses, ordered from least invasive to most.

1. Keep slot 05 disabled when you care about the alignment alerts. On the default three-slot configuration, or any configuration that stops at slot 04, the alignment alerts behave as designed. If the reason you were reaching for slot 05 was "more is better," this is also the response that lets you notice that more may not actually be buying you anything. A three-slot alignment where each slot is pulling in the same direction across different timeframes carries more real meaning than a five-slot alignment where slots 04 and 05 are mild noise added for its own sake.

2. Build alignment externally. Wire all enabled per-slot bullish (and bearish) alerts to a downstream system that tracks slot state across alerts and evaluates alignment yourself. Use the named hidden plot placeholders described below to surface active counts in the alert payload so the downstream logic has what it needs without needing to wire every slot separately. This is the response for a reader who has a genuine reason for slot 05 in the blend and still needs alignment notifications.

3. Rely on per-slot and blend alerts without alignment. If alignment was a confidence-booster rather than a necessity, naming the thing you were really using it for often reveals that the per-slot and blend alerts already cover the job. Honest subtraction is better than silent dependence on an alert that does not fire.

A cross-reference that matters

The troubleshooting page carries a first-class row for this symptom under the heading "alignment alert never fires when slot 05 is enabled." The limitations-and-trust-boundaries page names the same disclosure in its own language. The README mentions it in a short paragraph at the top. All four disclosures exist because a single mention would get missed by a reader who opens only one page.

If your system depends on these two alerts, verify your configuration does not enable slot 05 before you wire them live.

The two divergence alerts

• Blended Stoch Bullish Divergence: a bullish blended-K divergence has just confirmed.

• Blended Stoch Bearish Divergence: a bearish blended-K divergence has just confirmed.

Timing

The divergence alerts fire on the confirmation bar of a divergence. The confirmation bar is Pivot Len bars to the right of the actual pivot, because ta.pivotlow/ta.pivothigh use a symmetric left-and-right lookback.

Plot On Pivot? does not change the alert timing. When you enable Plot On Pivot?, the drawn triangle back-shifts over the original pivot bar; the alert still fires on the confirmation bar.

This is a meaningful distinction for anyone wiring the alert into an external system:

• The alert fires at bar T.

• The triangle draws at bar T minus Pivot Len (with Plot On Pivot? on) or at bar T (with it off).

• The pivot the divergence describes formed at bar T minus Pivot Len.

Your downstream system receives the alert at T. If you want to track the actual pivot bar, subtract Pivot Len from the alert timestamp yourself or include a timestamp offset in the alert message.

Condition

The divergence alert condition is Show Div enabled and the corresponding blended-K divergence boolean true. Turning Show Div off does not just hide the triangle — it also silences both divergence alerts.

Common misread

"I enabled Plot On Pivot? and the alert came through late." The alert is not late. The drawing is early. You are receiving the alert at the exact moment the divergence confirmed; the triangle you see on the screen was drawn onto a bar that was Pivot Len bars in the past.

Alert message templates

The default message body for every alert uses {{ticker}} and {{interval}} as placeholders. Rewrite the body in the TradingView alert dialog when you want more information in the notification.

Two advanced placeholders are worth knowing about because they are not in the UI and a reader will never find them without being told.

Named hidden plot placeholders — active slot counts

The script exposes two hidden plots using display.none. Hidden means they do not draw on the pane and they do not clutter the legend, but they are still available in the alert dialog's plot placeholders. Reference them by title, not by numeric {{plot_0}} / {{plot_1}} shortcuts, because many visible plots are declared before these hidden count plots.

• {{plot("Active Bullish Count")}} is the number of enabled slots that are currently bullish (K above D).

• {{plot("Active Bearish Count")}} is the number of enabled slots that are currently bearish (K below D).

These are invaluable for debugging alignment alerts and for building external alignment logic. A message body like "{{ticker}} {{interval}} bullCount={{plot("Active Bullish Count")}} bearCount={{plot("Active Bearish Count")}}" gives your downstream system enough information to reconstruct alignment across slots without needing to wire all ten per-slot alerts.

A worked wiring example

Suppose you want a webhook on every per-slot bullish fire that includes the slot number, the active bullish count, and the active bearish count. Message body:

Slot bullish on {{ticker}} {{interval}} :: bullCount={{plot("Active Bullish Count")}} bearCount={{plot("Active Bearish Count")}}

Create one alert per per-slot bullish condition. In each alert's message body, replace "Slot bullish" with "Slot 01 bullish", "Slot 02 bullish", and so on. Your downstream system now has, on every fire: which slot fired, what the overall bullish count was at that moment, and what the bearish count was. That is enough to build external alignment without depending on the built-in alignment alerts.

A short inventory of alert anti-patterns

• Wiring both alignment alerts with slot 05 enabled. They will never fire. See the disclosure above.

• Treating a per-slot bullish alert as a cross event. It is a state alert. Build cross logic yourself or throttle externally.

• Wiring the bullish divergence alert to an entry order. A confirmed divergence describes a prior pivot; it does not make a forward call. The workflows and limitations pages say why. This wiring misuses the tool and misuses the reader.

• Wiring the blend bullish alert to an entry order without a separate exit logic. The state alert will keep firing every bar the blend is bullish. Without external exit logic, your entries will stack.

• Forgetting that master smoothing delays the blend alerts. If you enabled master smoothing for cleaner plots and then wire the blend alert to a latency-sensitive system, expect the alert to arrive a beat later than the unsmoothed version would.

• Ignoring the named hidden count placeholders. They are the most useful debugging tool the alert surface exposes. Use them. A message with raw counts in it is vastly more useful than a message with a generic "bullish fired" string.

Verification path

Before trusting any alert live, run this sequence on a 1m chart at defaults:

1. Create a per-slot bullish alert on slot 01. Set frequency to "Once Per Bar Close." Watch the alert log for the first confirmed bar after slot 01 goes bullish; confirm it fires. Watch the next confirmed bar; confirm it fires again (state alert, repeat). Let it run for ten bars.

2. Disable slot 01 from the Settings panel. Confirm the alert stops firing even though the underlying condition would have been true on a running slot.

3. Re-enable slot 01. Create a divergence bullish alert. Wait for a confirmed bullish divergence. Note the timestamp of the alert and compare it to the timestamp of the pivot bar — the gap should equal Pivot Len bars.

4. Enable Plot On Pivot?. Wait for the next confirmed divergence. Note that the triangle back-shifts onto the pivot bar but the alert fires at the confirmation bar, same as before.

5. Enable slot 05 and configure the five slots to all be bullish (you may have to wait for a real alignment, or force one with input changes). Wire the All Stoch Slots Bullish alert. Confirm that it does not fire. Disable slot 05 and re-run the test; it should fire.

That is five minutes of work. It will keep you from trusting an alert on false pretences.

Where to go next: MTF and repainting before changing any On Bar Close? input, Troubleshooting for symptom-to-cause rows that cover the alignment-alert symptom and the state-alert-repeats symptom, Limitations and trust boundaries for the honest edges around the alert surface.