Level 10 · Lesson 13
Alert Architecture
(Free Tier)
Seven patterns. One alert slot. The engineering craft that turns a scarcity constraint into an information-density discipline.
First — Why This Matters
The 1-Alert Problem Is Universal.
You’ve learned the seven playbook patterns from 10.12. Each deserves surveillance. Each fires in specific market conditions you can’t predict in advance. TradingView Free gives you exactly one alert slot. The naive response is to pick your favorite pattern and alert on that; the cost is being blind to the other six.
This is not a TradingView-specific problem. Every notification channel in trading has a scarcity constraint — phone notifications, email inbox, Discord messages, your own attention budget. The architectural question is the same everywhere: given N setups and K << N notification slots, how do you design the K slots to carry maximum information?
This lesson teaches the engineering craft. Multi-condition OR logic. Dynamic message strings. Priority tier hierarchies. Pine Script patterns for alert conditions. Alert hygiene as a feedback system. Once-per-bar vs once-per-bar-close timing. Webhook basics. And when to upgrade, if ever. By the end, one alert slot will cover seven patterns comfortably, and you’ll know exactly which fired from the notification text alone.
🔎 THE ALERT AXIOM
A notification is a scarce channel. Its value is measured by information density per fire, not by frequency of fires. Design channels to maximize information per fire — the rest is hygiene.
01 — The Alert Compression Doctrine ⭐
Scarcity as Information Density Discipline
Seven patterns. One slot. The naive move is to pick a favorite. The doctrinal move is to recognize that the slot constraint isn’t a coverage limitation — it’s a design constraint that forces information-density thinking. Combine all seven patterns into one boolean via OR logic, then use a conditional message string to encode which pattern fired. One slot, seven patterns, full coverage, zero trade-off.
🏘 The Alert Compression Doctrine
When you have N setups but only K << N alert slots, each alert becomes a scarce channel that must carry maximum information per fire. The doctrinal response is to design a composite alert firing on ANY of the K most valuable patterns, with message text that encodes which pattern fired. This turns the scarcity constraint into an information-density discipline — not a coverage sacrifice. Works on TradingView Free (1 slot), Essential (20 slots), and every other platform with slot limits.
Three portable applications:
- 1. Multi-condition OR logic. One alert slot surfaces multiple patterns via boolean OR; dynamic message strings identify which one fired. 7-pattern coverage on 1 alert.
- 2. Priority hierarchies. Not all patterns deserve equal alert access. Rank by Rarity × Edge-per-Fire; low-frequency / high-edge patterns (Trap, Absorption) get S-tier over frequent ones (Launch).
- 3. Alert hygiene. Every fire without a trade teaches you something: pattern lower-quality than expected, or filters too loose. The alert log is P&L-adjacent data; treat it that way.
02 — Mechanics
How TradingView Alerts Actually Work
Before designing the architecture, understand the pipeline. On each new bar tick, TradingView’s servers run your Pine Script’s alert conditions. If any evaluates true, the alert fires, generating a message delivered through your configured channels (email, mobile push, webhook). Crucially, this runs server-side — alerts work whether your chart is open or not, whether you’re connected or not. You can design alerts you never watch on-screen.
💡 Server-Side Is the Point
If alerts only ran when your browser was open, they’d be useless — you could just watch the chart directly. The value is that TradingView’s servers evaluate your conditions 24/7 and push notifications when conditions fire. This means your architecture needs to work without your attention, not because of it. Every design decision that follows — message text, frequency settings, priority tiers — is optimizing for the moment you receive a notification cold, with no context.
03 — The Single Condition Trap
Why Alerting on One Pattern Is Wrong
The intuitive mistake: "I have 1 slot, I\u2019ll use it for my best pattern." Here’s the cost. Over a single trading session, 3-5 different patterns will typically fire. Your one-pattern alert catches 1 of them; the other 2-4 fire silently. You see them only if you happen to be staring at the chart at the exact moment. Most you miss. The trap is that this feels like focus — but it’s actually systematic blindness to 80%+ of your tradable setups.
💡 Favorites vs Architecture
Picking a "favorite" pattern for your single alert conflates two different questions: which pattern do you trade most often (favorite) vs which patterns do you need to be notified about (coverage). They’re completely different. Your favorite might be easiest to catch manually precisely because it’s so familiar; the ones you miss are the less-familiar ones you don’t instinctively scan for. Coverage is an architecture problem, not a preference problem.
04 — Multi-Condition OR Logic
The Foundational Technique
The first move in compression architecture: combine N boolean pattern conditions into a single fire signal via OR. In Pine Script: fire = p1_launch or p3_fade or p4_absorption or p7_trap. The alert fires when ANY condition is true. You have all four patterns covered in one alert slot. Simple, universal, works on every indicator, every platform.
💡 The OR Is Cheap
Boolean OR operations are computationally free and Pine Script has no limit on how many you can chain. You can literally OR together all seven playbook patterns and Pine won’t notice. The only thing that makes stacking N patterns "expensive" is the downstream consequence — more conditions firing means more alert notifications. But the OR itself costs nothing. So go wide: include every pattern you want surveillance on.
05 — Dynamic Message Strings
Encoding Which Pattern Fired
OR logic gives you one fire signal, but you’ve lost information: which pattern actually triggered? The solution is a conditional message string using Pine’s ternary operator: msg = p1 ? "🚀 LAUNCH" : p3 ? "📉 FADE" : p4 ? "🛡 ABSORB" : "UNKNOWN". When the alert fires, the message text identifies the specific pattern. The notification on your phone tells you exactly what happened, no chart-opening required for first assessment.
💡 Template Placeholders Too
TradingView supports template placeholders in alert messages: {{ticker}}, {{close}}, {{time}}, {{plot_0}}. Combine with your dynamic pattern string for notifications like "🚀 LAUNCH on {{ticker}} at {{close}} \u2022 MER 76". This gives you pattern, ticker, price, and supporting reading in one line — enough to make a first-pass trade decision from the notification alone.
06 — Priority Hierarchies
Ranking the Seven Patterns
Not all patterns deserve equal alert access. The ranking framework: Rarity × Edge-per-Fire. Rare patterns deserve the slot because they’re the ones you’re most likely to miss manually. High-edge patterns deserve the slot because the cost of missing them is high. Patterns that score high on BOTH axes (Absorption Reversal, Trap Fade) are S-tier. Frequent patterns (Compression Coil) are C-tier because you’d catch them anyway. This ranking shapes your architecture.
💡 S-Tier Gets Louder Alerts
On Free plan with one slot, all tiers share the alert but the message text can reflect tier: msg = tier_S ? "🚨 S-TIER: ..." : tier_A ? "\u26A1 A-TIER: ..." : "B/C: ...". Your phone’s notification sound or visual cue differentiates S-tier urgency from B-tier maybe. When you upgrade to paid plans, you can split tiers across separate alerts with distinct notification profiles. Either way, the tier ranking is what tells you how fast to respond.
07 — Pine Script Patterns
Three Canonical Code Shapes
There are three Pine Script patterns for alert conditions you should know. Pattern A: simple OR — works for static coverage. Pattern B: dynamic message — OR + conditional message string for pattern identification. Pattern C: priority tiered — builds tier boolean groups, OR’s them, conditional message by tier. Most architectures end up at Pattern C; Pattern B is the minimum viable; Pattern A is the starting scaffolding. The animation cycles through all three.
💡 alert() vs alertcondition()
Two Pine functions matter. alertcondition() is the classic: declares a condition that the user manually arms via the alert dialog. alert() is the newer function: fires programmatically during Pine execution, supports dynamic message strings via concatenation, and is required for the Compression Architecture. Use alert() for anything involving dynamic messages; alertcondition() is legacy for simple static cases.
08 — The Compression Architecture
The Reference Design
Here’s the complete reference architecture, as a system diagram. Seven pattern conditions feed into four tier groupings (S/A/B/C). Tiers OR into a single fire signal. A message builder reads the active tier and the specific active pattern, constructing the notification text. One alert slot delivers the message. This is the canonical design — every serious ATLAS user ends up at some variant of this, scaled to however many patterns they track and however many alert slots they have.
💡 The Architecture Is Reusable
This same four-layer structure (patterns → tiers → OR → message) works for any number of patterns, any number of tiers, any number of slots. On Free, one alert holds the whole architecture. On Premium (400 slots), you can split by tier, by ticker, by timeframe. The architecture doesn’t change — only the scale does. Master this shape and you can build alert systems of any complexity using the same mental model.
09 — Alert Hygiene
The Log Is P&L-Adjacent Data
Every alert fire teaches you something. Classify each fire into one of three categories: trade (alert fired, you took a trade), no-trade (alert fired but context correctly kept you out — FOMC, meetings, etc.), noise (alert fired in conditions that invalidated the pattern). Target: <20% noise. Above 30% means filters are too loose on specific patterns. Review noise fires, find the common invalidating factor, tighten THAT pattern’s condition.
💡 Noise Isn’t Free
Every noise alert costs you alert fatigue. Ignored alerts become habitual, and eventually you miss real ones too. A well-tuned architecture targets 10-20% noise — enough to stay engaged, few enough to remain trustworthy. Under 10% probably means filters are too tight (you’re missing valid fires). Over 30% means filters are too loose. Review the log weekly. Adjust one pattern at a time so you can measure the impact of each change.
10 — Bar Timing
Once-Per-Bar vs Once-Per-Bar-Close
A critical Pine decision: when does the alert fire within a bar? Once-per-bar fires the moment the condition first becomes true intra-bar — fast, but susceptible to the repaint problem when multi-indicator confluence conditions flip during bar formation. Once-per-bar-close waits for the bar to close with the condition still true — slower, but signals are confirmed. For diagnostic patterns depending on multi-indicator state, default to once-per-bar-close. For event indicators (ERD vacuum / absorption markers), once-per-bar is appropriate because events are inherently intra-bar.
💡 Repaint Is the Failure Mode
A repaint happens when an intra-bar signal fires on conditions that later invalidate at bar close. You get notified of a "LAUNCH" pattern, open your chart 3 minutes later to find nothing there — the bar closed with MER back in grey. The fire was real at the time but dissolved before the bar committed. Once-per-bar-close prevents this by definition: the alert only fires on commit. Accept the slight lag; the signal integrity is worth it for diagnostic patterns.
11 — Webhook Integration
Alerts as HTTP POST
Beyond email and push notifications, TradingView alerts can POST to a webhook URL — an HTTP endpoint of your choosing. Free plan includes one webhook URL per alert. The POST body contains your message text (with placeholders resolved), so the receiving system knows exactly what fired. This enables Discord channel posts, Slack messages, custom trading bot triggers, or any integration you want to build. The JSON-formatted body is the handoff point.
💡 Discord Webhooks Are Free and Easy
Simplest useful webhook integration: create a Discord channel, generate a webhook URL in channel settings, paste into TradingView’s alert webhook field. Format your message as JSON like {"content":"🔔 LAUNCH on {{ticker}}"} and Discord renders it as a channel message. You can share this channel with trading partners, or use it as a personal history log you can search. Zero infrastructure, all benefits. Slack follows the same pattern.
12 — Scaling Up
When to Upgrade, What Unlocks
The progression: Free (1 alert) → Essential (20 alerts) → Plus (100 alerts) → Premium (400 alerts). More slots mean less compression needed. But upgrading is architecture-first: don’t upgrade because more slots are available; upgrade when the compression architecture hits a real workflow constraint (distinct webhook routing per tier, per-tick frequency for specific patterns, multi-ticker parallel monitoring). For most traders, a well-tuned Free-tier compressed alert covers everything needed.
💡 The Compression Architecture Works on All Plans
The four-layer design (patterns → tiers → OR → message) is valid on every plan. Free plan enforces maximum compression — everything in one slot. Essential lets you split by tier. Premium lets you split by tier + ticker + timeframe. But the architecture doesn’t change; only the parallelism does. Start with Free and run the compressed architecture until it demonstrates a specific workflow constraint you can’t work around — then upgrade specifically to resolve that constraint.
13 — Common Mistakes
Four Ways Alert Architecture Breaks Down
Each mistake comes from skipping a step of the Compression Doctrine — picking favorites, omitting dynamic messages, misusing per-bar frequency, or ignoring the log as feedback.
Single Pattern Alert — alerting only on your favorite
The naive default: pick one pattern (usually #1 Launch), alert only on it, ignore the other six. The cost is systematic blindness — when #3 Fade or #4 Absorption fires during the same session, you’re not notified, so you miss them unless you’re staring at the chart. The Compression Doctrine solves this at zero cost: OR logic combines all patterns into one alert slot, dynamic message tells you which one fired. One slot, full coverage. Picking favorites is a category error — favorites shouldn’t determine coverage; architecture should.
Generic Alert Message Text
Alert fires, notification reads "ATLAS triggered." You don’t know which pattern, which ticker, what context. You have to open the chart to find out. By then, the setup has often resolved. The fix is dynamic message strings: encode the pattern name, key readings, and ticker directly in the message. You should be able to make a trade decision from the notification alone, before opening the chart. message = "🚀 LAUNCH on {{ticker}} at {{close}} • MER 76 • LDN-NY" tells you everything you need.
Per-bar frequency on all conditions — repaint hell
Using alert.freq_once_per_bar on diagnostic patterns means the alert fires the moment a condition first becomes true intra-bar. But these patterns depend on multi-indicator confluence that can flip — MER bounces between grey and teal, MSI wavers between regimes. You get phantom alerts that invalidate at bar close. Result: 20 noise alerts per session, alert fatigue, ignored fires. Default to once_per_bar_close for diagnostic patterns; exception only for event-type indicators (ERD markers) where intra-bar firing is the point.
Alert log ignored — no filter tuning, no learning
Each alert fires is data. Classify: trade (alert produced a taken trade), no-trade (alert fired but context correctly kept you out), noise (alert fired in conditions that invalidated the pattern). Target: <20% noise. If noise hits 30%+, specific patterns need tighter filters — review the noise fires, find the common failure mode, adjust that pattern’s condition. Traders who never review their alert log keep firing the same noise alerts forever and never improve filter quality. Logs are P&L-adjacent data; hygiene is the discipline of treating them that way.
14 — Cheat Sheet
Alert Architecture in One Page
Core Doctrine (★)
N setups, K << N slots → each slot must carry maximum information per fire. OR logic + dynamic message covers all patterns.
Pine Template
fire = p1_launch or p3_fade or p4_absorb
msg = p1_launch ? "🚀 LAUNCH..." : p3_fade ? "📉 FADE..." : "🛡 ABSORB..."
if fire
alert(msg, alert.freq_once_per_bar_close)
Priority
Rank by Rarity × Edge. S-tier: Absorption (#4), Trap (#7). A-tier: Fade (#3), Surge (#6). B-tier: Launch (#1), Handoff (#5). C-tier: Coil (#2).
Timing
Diagnostic patterns → once-per-bar-close. Event markers → once-per-bar.
Hygiene
Classify each fire: trade / no-trade / noise. Target <20% noise. Review weekly, tighten specific patterns producing noise.
Webhook
Free plan = 1 webhook URL. Discord channel webhook = simplest useful integration. JSON body carries resolved message.
Upgrade Trigger
Upgrade when architecture hits a specific workflow constraint, not when more slots are simply available.
15 — Scenario Game
Architect the Alert
Five scenarios testing whether you apply the Compression Doctrine, the Rarity × Edge priority framework, the hygiene feedback loop, and the timing discipline — or whether you still default to one-pattern thinking.
Round 1 of 5
Score: 0/5
You’ve just finished Level 10.12 and identified your starter playbook: #1 Launch, #5 Handoff, #6 Surge (trend trader). You have TradingView Free with 1 alert slot. Your first instinct is to alert only on #1 Launch since it’s your favorite pattern. Assess.
16 — Knowledge Check
Final Quiz — 8 Questions
Question 1 of 8
The Alert Compression Doctrine states that when you have N setups but only K << N alert slots:
Question 2 of 8
The foundational technique for fitting N patterns into 1 alert slot is:
Question 3 of 8
For priority-tier ranking of patterns, the correct framework is:
Question 4 of 8
For diagnostic patterns (Launch, Fade, Absorption) involving multi-indicator confluence, the correct alert frequency setting is:
Question 5 of 8
Alert Hygiene treats the alert log as:
Question 6 of 8
When should you upgrade from TradingView Free to Essential/Plus/Premium?
Question 7 of 8
Webhook integration on TradingView Free allows:
Question 8 of 8
The common failure mode "Single Pattern Alert" refers to: