Alerts
This page is about what each alert commits to, what it refuses to commit to, and how to wire the alerts into a process without handing them more authority than they deserve. There are ten alerts in total, they are all...
Written By Axiom Admin
Last updated 22 days ago
Alerts
This page is about what each alert commits to, what it refuses to commit to, and how to wire the alerts into a process without handing them more authority than they deserve. There are ten alerts in total, they are all state descriptors, and none of them is an entry or an exit. The rest of the page is about what those sentences actually mean in practice.
The reason the page is this long, and this insistent on the state-descriptor distinction, is that alerts are the surface where good intentions about a tool degrade into bad usage fastest. A pane you read with your eye keeps you in the loop. An alert wired to a webhook does not. The moment a state-descriptor alert reaches an automated downstream system that treats it as an event, the system starts acting on a misreading the indicator did not commit. The pack would rather be repetitive than let a reader drift into that mistake quietly.
If you have not yet looked at the pane during a normal session, Visuals and Logic is the faster first read. Alerts become easier to wire once the visual meaning is already familiar.
The ten alerts at a glance
There is no crossing-at-level alert on this trim. There is no divergence alert. There is no flip-only variant of any of the ten above. If you expected one of those, the Honest Gaps section below names it and says what your options are.
The single most important thing to internalize
These ten alerts are state descriptors, not edges. The per-slot bullish alert does not fire when the slot crosses up through its signal. It fires on every confirmed bar while the slot's CVD is above its signal. Wire a bullish alert and leave it, and TradingView will re-fire it on every bar close for as long as the state holds.
This is a deliberate design, not a bug. State-descriptor alerts are the easier primitive to build other logic on top of, because the receiving side can decide whether it cares about the whole sustained state or only the transitions. An entry-generator that wanted a "flip" behavior would have to be opinionated about what "flip" means on ambiguous bars; a state descriptor is not opinionated, and the opinion lives on the receiving side.
If you want flip-only behavior, add your own edge detection on the side that receives the alert. The script does not do it for you.
Confirmed bars, not intrabar
Every one of the ten alerts AND-gates on barstate.isconfirmed. In plain language: an alert can only fire at the close of a confirmed bar on your chart's timeframe, not mid-bar, not before the bar closes.
Two consequences:
You will never see an alert fire while a bar is still forming. Even with On Bar Close OFF on the indicator, the alert still waits for the chart bar to close. The intrabar line movement is visible on the pane; it is not forwarded to alerts.
The alert's timing is the chart bar, not the slot bar. A 5-minute chart fires alerts every five minutes at bar close. A 1-hour chart fires them every hour. This matters when you mix alert cadence with slot timeframes β a 60-minute slot's state can flip mid-hour on a 5-minute chart, and you will see the corresponding per-slot alert on the next 5-minute bar close, not at the next hourly boundary.
What each alert commits to
Per-slot bullish and bearish alerts (1β6)
Commits to: the named slot's CVD is above (or below) the named slot's signal at the last confirmed bar on the chart timeframe, and the slot is currently enabled on the indicator.
Does not commit to: price direction, blend state, alignment with the other slots, or the magnitude of the gap between CVD and signal. A hair-crossing produces the same alert payload as a decisive crossing.
Post-alert verification: look at the pane and confirm the named slot's line is in the up (or down) tone. If the pane disagrees with the alert, something is off β most likely the chart was reloaded mid-alert, or the script was toggled, or the alert was wired against a different instance of the indicator. Re-create the alert against the current instance.
Blended bullish and bearish alerts (7β8)
Commits to: the blended CVD is above (or below) the blended signal at the last confirmed bar on the chart timeframe, computed over the currently enabled slots with their current weights.
Does not commit to: slot agreement. A "Blended CVD Is Bullish" alert fires even when the three slots are spread across the pane and the blend is technically above the blended signal by a hair. The blend is a weighted mean; it does not tell you whether the underlying slots agree. If you care about agreement, you want alerts 9 and 10.
Alignment alerts (9β10)
Commits to: every enabled, currently-valid slot is on the same side of its signal at the last confirmed bar. Slots that are enabled but returning na (typical during the first few bars after a chart load while intrabar data warms up) are excluded from the count. The alert fires only when the remaining counted slots all agree.
Does not commit to: the blend state, the distance between each slot's CVD and its signal, or the timing relationship between the agreements. A single bar where the slots happen to line up is enough to fire the alert β and the next bar, as long as they still agree, it will fire again.
Post-alert verification: look at the pane and count the slot colors. Every enabled slot should be in the same tone. If you see two lime slots and one red slot, the alert did not fire from this bar; it fired from an earlier bar while all three agreed.
Repeat-fire behavior in practice
Here is the behavior that catches new wiring most often. Suppose:
You add
CVD 01 Is Bullishon a 5-minute chart.At bar close of the 10:05 bar, CVD 01 is above its signal. Alert fires.
At bar close of the 10:10 bar, CVD 01 is still above its signal. Alert fires again.
At bar close of the 10:15 bar, CVD 01 is still above its signal. Alert fires again.
At bar close of the 10:20 bar, CVD 01 has crossed below its signal. Alert does not fire. The
Bearishalert (if wired) would fire instead.
This is correct behavior. The alert is reporting on a state. As long as the state holds, the report keeps being made. If you want a single ping per flip, add flip detection on the receiving side β for example, ignore repeated alerts on the same state within a trailing window, or require the alert to stop firing for at least one bar before counting the next one as a new flip.
For readers wiring into webhooks, Discord channels, or pager services, the repeat behavior is usually the thing that surprises them first. Plan for it. A noisy channel is not a signal quality problem; it is a wiring choice.
Alignment after a reset
The alignment alerts have one specific failure mode worth preempting. After a session reset on a thinly-traded session β the first several bars of a new daily window on a session-traded instrument, for example β every slot has just been renormalized and is working with a freshly initialized range. In that stretch, the three slots can transiently lean the same way because they are all calibrating, not because the market is uniformly leaning.
If the All CVD Slots Bullish alert fires on the first bar or two after a reset, do not treat it as a regime statement. A pause of several bars after a reset is the right posture for alignment-driven workflows. The Workflows alert-triage pattern builds this pause in explicitly.
Disabled slots and alignment
Alignment alerts look at enabled slots only. An explicitly disabled slot (Enable CVD 0N turned off in the Inputs dialog) does not count. A slot that is enabled but currently returning na also does not count β the alert evaluator is explicit about this.
Practical consequences:
You can run a two-slot alignment read by disabling the third slot. The alignment alerts will fire on agreement between the two remaining slots.
You can run a one-slot "alignment" read by disabling two slots. The alignment alert will always fire whenever that single slot is on its declared side. That is a strange way to configure the pack and usually means you should just use the per-slot alert instead.
Warm-up bars on the indicator do not generate false alignment agreements. The
naexclusion prevents the alert from firing because the remaining slot is the only one reporting.
Alerts and Hide Plot
Hide Plot hides the slot's drawing. It does not change the slot's math, its contribution to the blend, or its alerts. A hidden slot still fires its bullish and bearish alerts and still counts in the alignment alerts.
If you want a slot's alerts removed from a pane while keeping its line visible, that is not a Hide Plot operation. Delete the alerts you do not want from TradingView's Alerts dialog. There is no indicator-side switch that disables a slot's alerts individually without disabling the slot entirely.
Alerts and Blended Weight = 0
Setting a slot's Blended Weight to 0 does not disable the slot, hide it, or silence its alerts. The slot continues to run, draw, and fire its own bullish and bearish alerts, and the slot continues to count in the alignment alerts. What changes is that the slot's CVD and signal no longer contribute to the blend.
This is often the right posture for a slot you want as context without letting it steer the blend β for example, a regime-frame slot you want to see and receive alerts from, while leaving the blend as a weighted mean of the two working frames.
Honest gaps
The script does not expose the following alerts. Naming them here because a reader is likely to expect at least one of them.
Crossing-at-level alerts. "Blended CVD crosses 80," "CVD 02 drops below 20," etc. Not exposed. The Overbought and Oversold lines are visual guides only. If you want crossing-at-level logic, the two options are: rely on your eye against the dashed guides, or build the crossing check on the receiving side using the alert payload (which does not carry numeric CVD values, so a pure TradingView alert-only implementation is not available on this trim).
Divergence alerts. "Price high but Blended CVD lower high," etc. Not exposed. Divergence against price is a qualitative read that lives in how you interpret the pane alongside the chart, not in a built-in alert.
Flip-only variants. "CVD 01 flipped to bullish," firing only on the crossing bar. Not exposed. The state-descriptor design is deliberate; flip-only logic belongs on the receiving side.
Crossing between blend and individual slots. "Blend crosses CVD 02," etc. Not exposed. The alerts work either on individual slots or on the blend; combinations are a receiving-side concern.
Master-smoothed-only alerts. The alerts are evaluated on the same lines you see on the pane. If Master Smoothing is on, the blended bullish/bearish alerts already use the smoothed values. There is no separate "smoothed-only" alert β it is already the smoothed values when smoothing is enabled.
Cadence mismatch β the trap nobody warns you about
A 60-minute slot's state can change halfway through a 5-minute chart's hour. The CVD 03 Is Bullish alert will not fire on the bar where the slot's state actually changed; it will fire on the next 5-minute chart bar's close. To you, looking at the chart later, it can read as if the alert fired in the middle of an obvious counter-move on the slot's own timeframe β which is exactly what happened, because the alert is gated on the chart bar, not the slot bar.
Two consequences worth carrying:
Reading "when did the alert fire" is not the same as reading "when did the state change." The state changed inside a slot bar that closed at some point during the chart bar. The alert fired at the chart bar's close. The lag between them is bounded by the chart timeframe.
Aligning your alert chart timeframe with the slowest slot you care about closes the gap. If your slowest slot is 60m and your chart is 5m, expect the alert to lag the slot's actual state change by up to one chart bar. If you put the alert on a 60m chart instead, the alert will fire only on 60m chart bar closes β but it will fire when the 60m slot bar itself closes, which is the rhythm the slot is operating on.
Neither posture is wrong. They have different cadences, and a triage process should know which it is using.
A minimal wiring pattern
If you are setting up alerts for the first time and want a defensible configuration that will not flood your inbox, the cleanest minimal pattern is:
Wire
All CVD Slots BullishandAll CVD Slots Bearishas the "everything agrees" pair.Wire
Blended CVD Is BullishandBlended CVD Is Bearishas the "summary changed" pair.Do not wire the six per-slot alerts initially. Come back and add them when you have a concrete reason β usually that you want to watch one specific slot's crossings independent of the blend.
Expect the alignment pair to be quiet most of the time and the blend pair to be moderately noisy. If the blend pair is noisy beyond your tolerance, two moves are legitimate: bump CVD Length and Signal Length by a bar or two (fewer small-gap crossings), or turn Master Smoothing on. Both add lag. Neither is a "fix" β they are explicit choices about how much twitch you want on the summary line.
Suggested reading from here
Workflows for the alert-triage pattern, where the state-descriptor design is built into the process.
MTF and Repainting for the full timing picture. Confirmed-bar gating is the alert-side answer to the same timing question On Bar Close handles on the slot side.
Visuals and Logic for the visual meaning behind each alert's evaluation.