Troubleshooting

This page is for the reader who is looking at something on the pane that does not match what they expected. Each row below starts with a symptom — the thing you see or do not see — and walks to a likely cause, a verification step to confirm the cause, and the fix. The rows are ordered roughly by frequency, with the hardest-to-diagnose items near the top so a reader who does not know where to look finds the common ones first.

Symptom-to-cause is more useful than generic advice. If you hit a problem not listed here, check the page that owns the relevant mechanic first: Settings for inputs, Visuals and Logic for what the pane shows, MTF and Repainting for timeframe and repaint behaviour, Alerts for alert wiring. This page exists for the specific moments where something concrete looks wrong.

1. Runtime error: "Stoch 0X timeframe cannot be lower than the chart timeframe."

Symptom. You add the indicator to a chart and immediately see a runtime error naming a specific slot number.

Likely cause. That slot's TimeFrame input is set to a value lower than the current chart's timeframe. The script checks every enabled slot's TF in seconds against the chart TF in seconds and refuses to run if any slot is below the chart.

Verification. Open Settings. Find the slot named in the error. Compare its TimeFrame value to your chart's timeframe (which TradingView shows in the chart header). If the slot's TF is strictly lower, that is the cause.

Fix. Pick one:

• Move the chart down to the slot's value or lower.

• Raise the slot's TimeFrame to the chart's value or higher, or leave it empty so it inherits the chart TF.

• Disable the slot if you did not intend to run it.

The error is by design, not a bug. The script refuses to compute a stochastic on a timeframe lower than the chart's because the chart cannot represent multiple slot values per chart bar without aggregating or picking arbitrarily.

2. Alignment alert never fires when slot 05 is enabled

Symptom. You have all five slots enabled, all five are bullish (or bearish) on confirmed bars, and the All Stoch Slots Bullish (or bearish) alert does not fire.

Likely cause. This is the upstream behaviour of the alignment counter. In the current implementation, the slot-05 branch increments activeSlotCount six times while the bullCount and bearCount variables still only increment once per bullish or bearish slot. The alignment check is an equality between bullCount (or bearCount) and activeSlotCount. Because activeSlotCount is too high whenever slot 05 is enabled, the equality can never be satisfied, so the alignment alerts never fire.

Verification. Disable slot 05. Reset the alert. Wait for a confirmed bar where all remaining enabled slots are bullish. The alert should fire. Re-enable slot 05; the alert stops firing on alignment conditions.

Fix. The manual does not fix the code. Your options:

• Keep slot 05 disabled when the alignment alerts matter. Pattern A and Pattern B in the workflows page run three and three slots respectively, and both work fine with these alerts.

• Build alignment externally by wiring all enabled per-slot bullish alerts to a downstream system that aggregates them. Use {{plot("Active Bullish Count")}} and {{plot("Active Bearish Count")}} to surface the active bullish and bearish counts in alert messages.

• If you need slot 05 in the blend and do not need the alignment alerts specifically, run without them. Per-slot and blend alerts are unaffected.

The alerts page and the limitations page carry the full disclosure; this row is the troubleshooting-side hook.

3. State alert fires every bar, not just on the cross

Symptom. You wired a per-slot bullish or a blend bullish alert. The alert fires on every confirmed bar the condition holds, not once on the cross.

Likely cause. These alerts are state alerts, not cross events. The condition is slot K > slot D (or for the blend, blend K > blend D) gated by barstate.isconfirmed. As long as the state holds, the condition is true on every confirmed bar, so the alert fires every confirmed bar.

Verification. Open the alert log in TradingView. Each fire is on a separate confirmed bar. The underlying condition is state-based; the repeat-fires are correct behaviour.

Fix. Three options:

• TradingView frequency: "Once Per Bar Close." This throttles to one fire per confirmed bar, which is the minimum rate of state-alert fires. You still get repeat fires while the state holds.

• TradingView frequency: "Only Once." This fires exactly once per alert session, the first time the condition becomes true after the alert starts running. Subsequent crosses will not fire.

• External cross detection. Wire the state alert to your downstream system and compute cross events yourself using bar-to-bar memory. This is the right approach for systematic operators who want one fire per cross and need the logic to survive alert restarts.

The indicator does not expose dedicated cross-event alerts. Build them externally if you need them.

4. Divergence marker appears later than expected

Symptom. You are waiting for a divergence to confirm. When it does, the triangle appears several bars to the right of the pivot that it describes.

Likely cause. This is Pivot Len. The divergence module uses ta.pivotlow(low, n, n) and ta.pivothigh(high, n, n) with symmetric lookback n = Pivot Len (default 20). A pivot is only confirmed once n bars to the right of the candidate bar have printed. The confirmation bar is where the alert fires and where the triangle draws at defaults.

Verification. Count the bars between the triangle and the chart-price pivot it is drawn against. The distance should equal your Pivot Len setting (20 by default).

Fix. Two options depending on what you want:

• Enable Plot On Pivot?. This back-shifts the drawing onto the original pivot bar. The triangle now sits over the pivot, which is more readable at a glance. Note the honest caveat: the triangle was not visible at that bar in real time; it is back-shifted after the fact. The alert still fires on the confirmation bar.

• Lower Pivot Len. Shorter lookback means faster confirmation, but also looser pivots and more triangles. "Looser" is a polite way of saying "noisier." The workflows page and the Settings page both treat lowering Pivot Len as a misuse when the motivation is "to see more divergences." Lower it only if you have a specific reason and will verify the resulting pivots look legitimate to you.

5. Blend line disappears from the pane

Symptom. The blend K and blend D stop drawing. The pane shows only reference guides and structure overlays.

Likely cause. The blend returns na when the total active weight is zero or when all enabled slots return na values. The plot draws nothing on na. Three paths produce this:

1. All enabled slots have weight 0. The weighted-mean total weight is zero; the blend is na.

2. All slots are disabled. No slot contributes, so there is nothing to blend.

3. Every enabled slot is returning na for some reason — typically a cross-symbol slot with no session data at the current chart time.

Verification. Open Settings and check:

• Are any slots enabled? If not, enable at least one.

• Do the enabled slots have non-zero weights? If every enabled slot has weight 0, raise at least one weight.

• Are any enabled slots using Optional Ticker for a symbol whose session may be inactive right now? If so, check that symbol's chart separately to see whether it is currently producing data.

Fix. Restore at least one enabled slot with a non-zero weight, and ensure that enabled slots are reading symbols that actually have data at the current chart time.

6. Slot K line does not appear even though the slot is enabled

Symptom. You enabled a slot but its colored K line does not draw on the pane.

Likely cause. Hide Plot is true for that slot. At defaults, slots 01, 02, and 03 have Hide Plot = true, so even though they are enabled and contributing to the blend, their individual K lines are not drawn.

Verification. Open Settings. Find the slot's Hide Plot input. If it is checked, the plot is hidden by design.

Fix. Uncheck Hide Plot. The slot's K line draws in its slot-specific colour (teal, aqua, blue, orange, or yellow, depending on slot number). When K is above D on that slot, the line glows in the full colour; when K is below D, the line dims. Re-check Hide Plot when you are done diagnosing to restore the clean default pane.

This is a common confusion because Hide Plot visually looks like an off switch but is actually a visibility control. See the Settings page on the dependency between Hide Plot, Enable, and Blended Weight.

7. I changed Source to HLC3 and the slot K looks the same as with close

Symptom. You change a slot's Source input from close to hl2, hlc3, or ohlc4, and the slot K line looks nearly identical to before.

Likely cause. ta.stoch(src, high, low, n) takes a source argument for the numerator and a separate pair of arguments — the bar's high and low — for the range denominator. The script always passes the bar's own high and low regardless of the source selection. Changing Source only moves the numerator (where the current value sits inside the bar's range). The range itself does not change.

On quiet, narrow-range bars the numerator is close to the midpoint of a narrow window no matter which source you picked, so the K line barely shifts. On wider-range bars the shift is more visible, but still bounded by the range itself.

Verification. Compare the slot K at Source = close against Source = hlc3 on bars where the intra-bar range is small. The K lines will be nearly identical. On bars with large intra-bar ranges, the K lines will differ slightly — but the range denominator is unchanged.

Fix. No fix needed; this is the designed behaviour of ta.stoch. If you want different range behaviour, the stochastic is not the knob — you would need a different indicator entirely. The Settings page and the Visuals and Logic page both name this explicitly.

8. Cross-ticker slot shows gaps or stale values

Symptom. You enabled Optional Ticker on a slot pointing at a different symbol, and the slot's K line shows flat stretches, jumps, or gaps that do not correspond to anything happening on the chart symbol.

Likely cause. The cross-ticker slot inherits the other symbol's session. If the other symbol is an equities ticker and the chart is a 24-hour futures contract, the cross-ticker slot has data only during the equities session. Outside the equities session, the slot either flattens or returns stale values.

Verification. Pull up the cross-ticker's own chart separately. Compare its session hours against your chart's session. If they differ, the gap pattern on the slot will line up with the cross-ticker's off-session.

Fix. Three options:

• Accept the session mismatch. The blend effectively rebalances onto the other slots during the cross-ticker's off-session. If that behaviour is acceptable, nothing to change.

• Match the sessions. Set the chart to a symbol with the same session as the cross-ticker, or change the cross-ticker to a symbol whose session matches the chart.

• Disable the cross-ticker slot if the session mismatch is producing more confusion than the cross-asset context is worth.

9. Master smoothing enabled and alerts feel sluggish

Symptom. You enabled Enable Smoothing to calm a choppy blend, and now blend-level alerts (Blended Stoch Is Bullish, Blended Stoch Is Bearish, or divergence alerts) arrive noticeably later than you expected.

Likely cause. Master smoothing applies an MA pass to both blend K and blend D after the weighted mean. Every downstream consumer reads the smoothed series. The K/D cross happens later on a smoothed pair, divergence pivots comparing smoothed values produce different confirmations, and Keltner/BBWP/Donchian all shift because their input shifted. The alert arrival time matches the smoothed series, not the unsmoothed series.

Verification. Toggle Enable Smoothing off. Watch the blend K and blend D react more quickly. Toggle back on and watch the lag return.

Fix. Decide which tradeoff you want:

• Smoothing on: cleaner plot, slower alerts, slower divergence confirmations.

• Smoothing off: choppier plot, faster alerts, earlier divergence confirmations — but also more false moves in the plot.

Per-slot alerts are unaffected by master smoothing because they evaluate slot K vs slot D, not the smoothed blend. If you want fast per-slot alerts and a smoothed blend plot, the default configuration already does that for you.

10. Plot On Pivot moved the triangle but the alert came in later anyway

Symptom. You enabled Plot On Pivot?. The triangle back-shifted onto the pivot bar. You expected the alert to arrive at that earlier bar, but it arrived at the confirmation bar as before.

Likely cause. Plot On Pivot? only changes the offset parameter on the plotshape drawing. It does not change the alert condition or the confirmation timing. The divergence module still requires barstate.isconfirmed on the pivot check, and the pivot itself still needs Pivot Len bars of right-side lookback to confirm. The alert fires on the confirmation bar regardless of how the drawing is rendered.

Verification. Compare the alert timestamp to the triangle's drawn position. With Plot On Pivot? on, the triangle sits Pivot Len bars to the left of the alert timestamp. With it off, they line up.

Fix. No fix needed; the alert is correct and the drawing is correct. The two are decoupled by design. Use the drawn position for readability on the chart; use the alert timestamp for wiring decisions. If your downstream system wants to know the actual pivot bar, subtract Pivot Len bars from the alert timestamp yourself.

11. Blend moved unexpectedly and I cannot see why

Symptom. The blend K and blend D shifted noticeably, but none of the visible slot plots moved enough to explain the shift.

Likely cause. A hidden slot or a weight-zero slot is doing work you cannot see. Three cases:

1. A hidden slot (one with Hide Plot = true) is contributing to the blend by weight. Its K moved and pulled the blend.

2. A weight-zero slot is not contributing, but you thought an enabled visible slot was more active than it actually is. The blend math is driven by weights you have not inspected recently.

3. Master smoothing is adding lag that makes the blend look like it is moving for reasons the instantaneous slot plots do not show — the blend is catching up to slot movement from bars ago.

Verification. Open Settings. For each enabled slot, note Enable, Hide Plot, and Blended Weight. Unhide all enabled slots temporarily. Watch the blend and the slot plots on the next confirmed bar. The slot pulling the blend will be visible now.

Fix. Re-hide slot plots after diagnosis. Adjust weights if the blend's sensitivity to a hidden slot surprises you. Disable master smoothing if you want blend motion to match slot motion more directly.

12. I set a slot's weight to zero and its alerts keep firing

Symptom. You set a slot's Blended Weight to 0 thinking it would silence the slot entirely. Per-slot bullish or bearish alerts from that slot continue to fire.

Likely cause. Weight zero silences the slot's contribution to the blend. It does not stop the slot from running, does not hide the slot's plot (unless Hide Plot is also on), and does not silence the slot's per-slot alerts. The per-slot alert condition is gated by slot0XEnable, not by weight.

Verification. Open Settings. Check that the slot's Enable is true and its Blended Weight is 0. Watch the alert log — per-slot bullish/bearish alerts continue to fire on confirmed bars.

Fix. For a real silence, set Enable Stoch 0X = false. That stops the slot from running, silences all its alerts, and removes it from the blend. The Settings page's dependency-pair section covers this distinction in detail.

13. BBWP column is tall but price looks calm

Symptom. BBWP is printing tall aqua columns, but the chart price is moving in a quiet range.

Likely cause. BBWP measures the Bollinger width of the blended K line, not of price. The blended K can be swinging through its 0..100 range while chart price is in a narrow band — small price moves translate to large stochastic moves when the bar-to-bar range is small. The oscillator is volatile in this regime even though price is quiet.

Verification. Look at the blended K line itself, not at BBWP. The blend K is probably moving between extremes of the 0..100 range on small price changes. BBWP is honestly reporting that oscillator volatility.

Fix. No fix needed. Read BBWP as a statement about the blended oscillator's own width regime, not about price. If you want price volatility, look at price: ATR, realized volatility, bar-range, whatever your normal volatility read is. The Visuals and Logic page and the Limitations page both name this as a recurring misread.

14. I changed a Power User block parameter and nothing happened

Symptom. You tweaked a value in an ALMA, KAMA, FRAMA, Jurik, Laguerre, or VAMA Power User block and the plot did not change.

Likely cause. Power User blocks only affect the compute when the paired MA family is currently selected. If your slot's K Type is set to SMA and you change a value in the ALMA Power User block, nothing happens because ALMA is not being used.

Verification. Find the MA family input that corresponds to the Power User block you changed. Check whether that family is currently selected. If not, the block is inert.

Fix. Either select the MA family you want to tune, or accept that the Power User block is not the knob you need right now. The Settings page has the Power User guidance; the Axiom MA Library Pro pack has the individual family internals.

Verification habits that prevent most of these symptoms

Most rows above are easier to prevent than to diagnose. A few habits that catch the problem before it becomes a symptom.

• Read Settings before you read the pane. On a fresh indicator load, open the Settings panel and glance at slot enables, weights, Hide Plot flags, and On Bar Close? toggles across every enabled slot. The pane is a projection of the Settings state. If Settings and pane disagree in your head, the pane is lying to you by omission — hidden slots contribute, weight-zero slots run, disabled slots do not appear at all. Five seconds in Settings prevents a lot of "why did the blend just move?" confusion.

• Keep On Bar Close? uniform across enabled slots unless you deliberately want mixed posture. Uniform is the safer default because it makes the blend say one clean thing about one consistent bar-state. Any divergence from uniform should be accompanied by a sentence you can say aloud: "Slot 03 is live because I want a forming-60m read; everything else is confirmed." If that sentence does not come easily, the mixed posture is probably accidental.

• Verify the slot-TF-at-or-above-chart-TF constraint the first time you load a new chart. A runtime error is cheap to fix at load time and annoying to fix during a session. When moving the chart up or down a timeframe, glance at the slot timeframes before you assume the indicator is still legal.

• Use the named hidden count placeholders in alert messages so notifications carry the active bullish and bearish counts. Debugging alignment, misfires, and spurious triggers is dramatically faster when the alert payload includes {{plot("Active Bullish Count")}} and {{plot("Active Bearish Count")}} instead of a generic condition string.

• Hover the blend plot on a forming bar to read the current K and D values from the status line. Eyeballing the pane is less reliable than the status line, especially at the extremes where the K/D gap gets small and the fill colour is hard to read. The status line is the truth; the fill is a convenience.

• When something looks wrong, change one input at a time. Two-input changes before a re-check double the number of possible causes for the next observation. The rows above assume you can attribute a change in pane behaviour to a specific input you just touched; that attribution is only reliable if you touched one input.

Where to go next: Settings for the input-by-tier breakdown referenced in several rows above, Alerts for the full alignment-alert disclosure and the placeholder details, MTF and repainting for timeframe and repaint rows in depth, Limitations and trust boundaries for the honest edges behind the recurring misreads.