Troubleshooting
This page is organized by symptom — what you see (or do not see) on your chart. For each symptom, it explains the likely cause, why it happens, and how to fix it. Some of these are setup errors. Some are misunderstand...
Written By Axiom Admin
Last updated About 1 month ago
Troubleshooting
This page is organized by symptom — what you see (or do not see) on your chart. For each symptom, it explains the likely cause, why it happens, and how to fix it. Some of these are setup errors. Some are misunderstandings. Some are genuine limits of the tool. Knowing which is which is part of learning to use it well.
When something looks wrong, the first question is always: is the tool misbehaving, or is your expectation misaligned with what the tool actually does? Most of the entries below are the second kind. The indicator is computing correctly — you are just seeing a result that does not match what you assumed it would show. That distinction matters because the fix is different. A broken tool needs a code change. A misaligned expectation needs understanding.
The indicator throws a runtime error on load
What you see: An error message in the Pine console. The indicator does not render. Nothing appears in the oscillator pane.
Likely cause: One of the enabled slots has a timeframe set lower than the chart timeframe.
Why it happens: The indicator enforces a hard constraint: every slot's timeframe must be equal to or higher than the chart's timeframe. If you are on a 15-minute chart and a slot is set to 5 minutes, the indicator cannot request 5-minute data to display on a 15-minute chart. It throws a runtime error and stops rather than silently producing bad data.
How to fix it:
Open the indicator settings.
Check each enabled slot's TimeFrame field.
Either increase the slot timeframe to match or exceed the chart timeframe, or clear the field entirely (an empty field inherits the chart timeframe, which always satisfies the constraint).
If you recently changed your chart timeframe, any slots with fixed timeframes below the new chart TF will cause this error.
What to understand: This is a safety feature, not a bug. The indicator could silently return garbage data for a sub-chart-TF slot, and many tools do exactly that. This one stops and tells you. The error message tells you which slot caused the problem. Read it carefully — it includes the slot label.
One or more slot lines are missing
What you see: Fewer lines than expected in the oscillator pane. Some slots appear to be producing no output.
Likely cause (most common): The slot's Optional Ticker field contains an invalid symbol, or the specified ticker has no data for the requested timeframe.
Why it happens: When a slot's security request returns no data, the slot's Fast and Slow values become na (not available). The line is not drawn for na values. The slot essentially drops out of the visual display — and out of the blend, since na values are excluded from the weighted average.
How to fix it:
Open settings and check the Optional Ticker field for the missing slot.
If the field has a ticker, verify the symbol is correct — typos are the most common cause.
Verify the ticker has data on the requested timeframe. Some instruments lack intraday data, or may not be available from your data provider.
Clear the Optional Ticker field to fall back to the chart symbol and confirm the slot reappears.
Other possible causes:
The slot is disabled (Enable is unchecked). Check the Enable toggle.
The slot is enabled but has "Hide Plot" checked. The slot is computing and contributing to the blend, but the line is not drawn. Uncheck Hide Plot to confirm the slot is actually producing data.
The slot's timeframe is set to a very high value (e.g., monthly) on a low-timeframe chart. The slot may technically be working but updates so infrequently that the line appears flat or invisible near zero.
The oscillator looks flat or barely moves
What you see: Lines in the oscillator pane, but they hover near zero with minimal movement. The oscillator appears unresponsive to price changes.
Likely cause: The slot timeframes are much higher than the chart timeframe, or the ATR Sensitivity is very low, or the MA Length is very short.
Why it happens (timeframe spacing): If you are on a 1-minute chart with slots configured for 240m, D, and W, the higher-timeframe slots update in steps and can spend long stretches looking quiet between their own closes. The oscillator is not broken — it is waiting on those higher-timeframe contexts to move.
Why it happens (low sensitivity): ATR Sensitivity below 0.5 compresses the normalized distance into a narrow band near zero. The oscillator is computing correctly, but the saturation curve maps the distance to a small range.
Why it happens (very short MA length): With a Length of 1 or 2, the baseline MA tracks price almost exactly. The distance between price and the baseline is always tiny. The oscillator reads near zero because there is almost no distance to measure.
How to fix it:
Adjust slot timeframes to be appropriate for your chart timeframe. A general guideline: the lowest slot timeframe should be within a few steps of the chart timeframe. A 15-minute chart works well with 15m/60m/240m slots.
If your slot timeframes are appropriate but the oscillator is still compressed, increase ATR Sensitivity (try 1.5 or 2.0).
If your MA lengths are very short, increase them. A length of 10 or above gives the baseline enough separation from price to produce meaningful distance readings.
The blended line does not match any individual slot
What you see: Three visible slot lines at +60, +40, and -20. The blended Fast line reads about +27. It does not seem to follow any individual slot.
This is correct behavior. The blended line is the weighted average of all enabled and weighted slot values. With three equally weighted slots at +60, +40, and -20, the weighted average is (60 + 40 + (-20)) / 3 = approximately +27. The blend does not select a slot — it averages them.
What to check if the blend seems wrong:
Are hidden slots contributing? A hidden slot with a high weight can pull the blend in a direction that does not match the visible lines. Check all slots — not just the visible ones.
Is one slot returning
na? If a slot drops out (bad ticker, etc.), the blend reweights around the remaining slots. The blend's character shifts when a slot disappears.Is Master Smoothing enabled? The master smoothing pass applies a moving average to the blended output, which adds lag and can make the blend appear offset from the individual slots.
Colors keep flickering on the current bar
What you see: A slot's line color rapidly alternates between its up-color and down-color on the rightmost (current) bar.
Likely cause: The slot has On Bar Close disabled, and the slot's Fast value is oscillating near its Slow value as new ticks arrive within the higher-timeframe bar.
Why it happens: With On Bar Close OFF, the slot updates in real time. When Fast is very close to Slow, small tick-level changes in price can push Fast above Slow (bullish color) and then below Slow (bearish color) within seconds. The color comparison recalculates with every update.
How to fix it (if the flickering is unwanted):
Enable On Bar Close for that slot. The values will update only when the HTF bar closes, eliminating intrabar flickering.
Increase the Slow Length for that slot. A longer Slow smoothing makes the Slow line less sensitive to the same intrabar fluctuations, reducing the frequency of Fast/Slow crossings.
What to understand: This is not a malfunction. It is the visual consequence of real-time updating near a crossover point. The flickering stops once the current bar closes and the values lock in. If it bothers you visually but you still want live-mode data from the slot, increasing the Slow Length by even one or two bars can meaningfully reduce the flicker frequency without sacrificing much responsiveness.
Alerts are firing every bar instead of once
What you see: A notification for the same alert on every bar, even though you expected a single notification when the condition first became true.
Likely cause: You set up a continuous alert (bullish regime, bearish regime, or alignment) instead of an event-based alert (regime flip, zero-line cross, overbought/oversold cross).
Why it happens: The per-slot bullish and bearish regime alerts, and the alignment alerts, fire on every confirmed bar where the condition is true — not just on the transition bar. If a slot stays bullish for 100 bars, the bullish alert fires 100 times. This is by design — some users want to know the condition is still active, not just that it started.
How to fix it:
If you want a single notification when the condition starts, use the Regime Flip alert instead. It fires once when the Fast/Slow relationship changes direction and does not fire again until it changes again.
If you want a single notification for blended direction changes, use the Blended Regime Flip or the zero-line crossover/crossunder alerts.
See Alerts for the full continuous-vs-event breakdown.
A slot shows a reading but I cannot verify it manually
What you see: A slot reads +55 but when you do the rough math (price minus MA, divided by ATR), you get a different number.
Why this might happen:
The slot is using a different timeframe from the chart. The MA and ATR are computed on the slot's timeframe, not the chart's timeframe. Your manual calculation may be using the chart-timeframe values.
The slot is using an Optional Ticker. The entire calculation — source, MA, ATR — happens on that ticker, not on the chart symbol.
The saturation curve is non-linear. Even if your ATR-normalized distance is correct, the mapping from that distance to the oscillator reading is not 1:1. See For the Geeks.
The ATR Sensitivity multiplier is applied before saturation. If sensitivity is not 1.0, your manual calculation needs to account for the scaling.
How to get a rough verification:
Add a separate ATR indicator (same length) to a chart of the slot's ticker and timeframe.
Add a matching MA (same type, same length) to that same chart.
Measure the distance between price and the MA at a specific bar.
Divide by the ATR at that bar.
Multiply by the ATR Sensitivity setting.
The result is the input to the saturation curve. If this value is around 0.5, the oscillator reading should be in the mid-range (roughly +40 to +50). If it is around 1.5, the reading should be near +75 to +85. If it is above 3, the reading should be near ±100.
This is an approximate check. Exact replication requires matching the saturation curve, which is proprietary. But the general relationship should hold.
The indicator is slow or causing chart lag
What you see: The chart feels sluggish after adding the indicator. TradingView's performance degrades, especially on lower timeframes.
Likely cause: Multiple enabled slots with cross-ticker requests or very high-resolution timeframes create multiple request.security() calls. Each call is a data request to TradingView's servers.
How to reduce the load:
Disable slots you are not actively using.
Avoid running many cross-ticker slots simultaneously on very low timeframes.
If you are on a 1-second or 1-minute chart with ten enabled slots, the indicator is making ten concurrent data requests per bar update. Reducing to three or four slots may noticeably improve performance.
What to understand: This is a TradingView platform constraint, not an indicator limitation. Each request.security() call consumes compute and data bandwidth. The indicator does not control how TradingView handles multiple concurrent requests.
The blended regime alert fired but the blend "looks" like it was already in that regime
What you see: A "Blended Regime Flip" alert fires, but looking at the chart, the blended fill color seems like it was already the same color before the alert bar.
Why this might happen:
Master Smoothing is enabled. The smoothing can cause the blended Fast to hover very close to the blended Slow for several bars before finally crossing. The fill might have looked like the same color to the eye, but Fast was actually still below Slow by a tiny amount — then crossed. The flip is real; the visual distinction was just too small to notice.
The flip was brief. The blended regime flipped for one bar and then flipped back. By the time you look at the chart, the flip has already reversed. You can verify this by checking the bar-by-bar data in TradingView's data window.
Quick reference: symptom to likely cause
A note on troubleshooting mindset
Most problems with this indicator fall into one of three categories: configuration errors (wrong timeframe, bad ticker), expectation mismatches (the tool is doing what it should, but you expected something different), and genuine edge cases (ATR at zero, na propagation through the blend). The first category has a quick fix. The second category requires re-reading the relevant part of the manual — usually Visuals & Logic or MTF & Repainting. The third category is rare and usually self-resolving when the data condition clears.
If you have worked through the entries above and the problem persists, check whether the issue reproduces on a different instrument or a different chart timeframe. This helps distinguish between an indicator problem and a data-provider problem on TradingView's side.