A complete guide to streamlining your trade notifications and connections for faster execution.
Most alert systems fail at the same point: a single condition fires, you get pinged, and by the time you look at the chart the context has shifted. Price touched a level, yes — but volume was half normal, the broader market was in freefall, and the setup was never valid. Single-condition alerts produce noise. Multi-condition alerts produce signal.
This guide is built around one core principle: an alert should only fire when at least two or three independent conditions converge. Not "price crossed $45,000" — but "price crossed $45,000 AND volume in the last 15 minutes is 1.8x the 20-day average AND RSI on the 4H just crossed above 50 from below." That third condition alone eliminates roughly 60% of false breakouts.
The architecture described here routes every alert through a tiered system before it reaches you. Alerts are classified at the point of generation, not at the point of receipt, into three levels:
This triage keeps a 24-hour alert flow manageable. Without it, even a well-designed system generates 40–80 pings per day. With it, Level 1 alerts average 2–5 per day for an active multi-pair crypto setup.
The delivery infrastructure runs TradingView as the condition engine, webhooks as the transport layer, and Telegram or Discord as the destination. TradingView Pine Script handles the logic evaluation. The webhook fires a JSON payload to a simple relay server (or directly to a Telegram bot) when conditions are met. Discord and Telegram receive the formatted message with context baked in — price, volume ratio, RSI value, and alert tier — so you are never reading a bare price notification that requires you to open a chart before you understand what you're looking at.
The failure modes are as important as the success paths. When a Level 1 alert fires at 3am and you are asleep, you need a pre-defined response rule that executes without you: a standing limit order that activates on alert, a conditional stop adjustment, or a hard pass rule that says "no Level 1 entries between 00:00 and 06:00 UTC — if it fires, it's a Level 3." That decision needs to be made during system design, not at 3am.
The final operational layer is A/B testing alert configurations against each other over rolling 30-day windows. You run Configuration A on BTC and Configuration B on ETH, track alert-to-valid-setup ratio and alert-to-executed-position ratio, and rotate in the better performer. Alert systems degrade as market structure changes. Quarterly tuning is not optional.
Everything in this guide is specific. You will find exact Pine Script syntax, exact webhook payload formats, exact Telegram bot setup steps, and exact multi-condition logic for the four most common crypto alert setups: breakout, support/resistance, funding rate extreme, and liquidation cascade. Use the configurations directly or adapt them. The goal is a system you can deploy in a day and tune over a quarter, not a framework you understand in theory but never finish building.
TradingView sits at the center of most retail crypto alert workflows for a reason: it combines the best charting environment with Pine Script, a purpose-built language for conditions, and native webhook support that fires on alert triggers without requiring you to run your own execution server. The webhook is the bridge. Understanding what lives on each side of that bridge determines how useful your alert system becomes.
On the TradingView side, the webhook is configured in the alert dialog. The URL field accepts any HTTPS endpoint. The message field is a JSON payload you define. TradingView sends a POST request to that URL every time the alert condition evaluates to true. That's the entire mechanism. There is no authentication header built in — you authenticate by using a secret token in the URL path or payload.
On the receiving side, you have several options. The simplest is a Telegram bot with a webhook listener hosted on a small VPS or a free-tier cloud function. AWS Lambda, Google Cloud Functions, and Render.com free tier all work. The relay script is 30 lines of Python. It receives the TradingView POST, parses the JSON, and forwards the message to a Telegram chat ID using the Bot API.
Here is the minimal Python relay for AWS Lambda:
import json
import urllib.request
TELEGRAM_TOKEN = "YOUR_BOT_TOKEN"
CHAT_ID = "YOUR_CHAT_ID"
SECRET = "your_secret_token"
def lambda_handler(event, context):
body = json.loads(event.get("body", "{}"))
if body.get("secret") != SECRET:
return {"statusCode": 401, "body": "Unauthorized"}
text = body.get("message", "Alert received")
url = f"https://api.telegram.org/bot{TELEGRAM_TOKEN}/sendMessage"
payload = json.dumps({"chat_id": CHAT_ID, "text": text, "parse_mode": "HTML"}).encode()
req = urllib.request.Request(url, data=payload, headers={"Content-Type": "application/json"})
urllib.request.urlopen(req)
return {"statusCode": 200, "body": "OK"}
The TradingView alert message body for this relay:
{
"secret": "your_secret_token",
"message": "🔔 <b>BTC BREAKOUT ALERT — LEVEL 1</b>\nPrice: {{close}}\nVolume Ratio: {{plot_0}}\nRSI: {{plot_1}}\nTime: {{time}}"
}
TradingView's {{close}}, {{time}}, and {{plot_N}} placeholders inject real-time values at the moment of alert fire. {{plot_0}} and {{plot_1}} reference plotted values in your Pine Script — which means you can surface any calculated value (volume ratio, RSI, funding rate proxy) directly into the notification.
The ccxt library becomes relevant when you want the relay to do more than route messages — specifically when you want it to place orders or adjust positions directly. The pattern is: TradingView detects conditions → webhook fires to relay server → relay places order via exchange API. This is automated execution, not just alerting. For a pure alert system, you do not need ccxt. For semi-automated execution where the alert also places a limit order at the current level, you do:
import ccxt
exchange = ccxt.bybit({
'apiKey': 'YOUR_KEY',
'secret': 'YOUR_SECRET',
})
# Place a limit order at the alert price
def place_limit_order(symbol, side, amount, price):
return exchange.create_order(
symbol=symbol,
type='limit',
side=side,
amount=amount,
price=price,
params={'timeInForce': 'PostOnly'}
)
The PostOnly parameter is critical for limit orders in this context — it ensures the order is canceled rather than filled as a taker if the price has already moved through the level by the time the order reaches the exchange. This prevents chasing fills that occur because of webhook latency (typically 200–800ms from TradingView condition to exchange receipt).
The Binance, Bybit, and OKX APIs all support WebSocket streams for funding rate, liquidation data, and order book depth. REST APIs handle order placement. Keep these roles separate: WebSocket for data ingestion that feeds your TradingView indicators via Pine Script data feeds or your own scripts, REST for execution. Mixing them causes rate limit issues under load.
Rate limits matter specifically for crypto alert systems because some setups (liquidation cascade detection, for example) can fire 20+ alerts in a 60-second window. At that volume, a relay that also places orders will hit exchange rate limits. Build a queue with a 100ms minimum spacing between order requests. For pure alert delivery to Telegram, Telegram's Bot API allows 30 messages per second to different chats, which is never a constraint in practice.
The physical and software environment determines latency. For pure alert delivery (TradingView → webhook → Telegram), total latency from condition-true to message receipt is typically 1–4 seconds, dominated by TradingView's internal alert processing delay. For automated execution, every millisecond compounds. For alert-only systems, the bottleneck is human response time, which makes sub-second delivery irrelevant compared to alert quality.
The practical environment for most active traders running a multi-pair alert system: a VPS (2 vCPU, 4GB RAM) hosting the relay server, TradingView Pro or Pro+ for multiple concurrent alerts (the free tier allows 1 alert, Pro allows 20, Pro+ allows 100), and Telegram or Discord for delivery. Total monthly cost: $6–12 for the VPS, $12–60 for TradingView depending on tier.
The TradingView alert limit is a real operational constraint. With a 4-pair, 3-timeframe setup (BTC, ETH, SOL, BNB on 1H, 4H, 1D), you need 12 alert slots at minimum — more if you run separate alerts for entries, invalidations, and information events. Pro+ at $60/month unlocks 100 alerts, which is sufficient for most setups. An alternative is to consolidate multiple conditions into a single multi-condition script that handles all pairs in one alert slot, which is addressed in Chapter 5.
Environment configuration checklist:
TradingView setup:
VPS relay server setup:
Telegram bot setup:
/newbot → name it → save the tokenhttps://api.telegram.org/botYOUR_TOKEN/getUpdatesDiscord webhook setup:
{"content": "your message"} for Discord webhooksA hardware note: the local machine you trade from matters less than the VPS stability. The relay server needs 99.9% uptime. Your local machine can be a standard laptop. What you want to avoid is running the relay as a local process — if your machine sleeps, restarts, or loses internet, alerts stop delivering and you won't know until you check manually.
For teams or copy-trading setups, the relay server becomes a fan-out router: one TradingView webhook fires, the relay delivers the same alert to multiple Telegram chats or Discord servers simultaneously. Add the target channels to a list and loop:
TARGET_CHATS = ["-100123456789", "-100987654321"] # channel IDs
for chat_id in TARGET_CHATS:
payload = json.dumps({"chat_id": chat_id, "text": text, "parse_mode": "HTML"}).encode()
req = urllib.request.Request(url, data=payload, headers={"Content-Type": "application/json"})
urllib.request.urlopen(req)
Backup alert delivery deserves explicit design. If the Telegram bot goes down (rare but possible), you want a secondary path. Configure TradingView to send email alerts as a fallback for Level 1 alerts. Set up a filter in your email client that pushes Level 1 subject lines to your phone's notification tray. This redundancy path has fired approximately once per quarter in practice — but when it fires, it matters.
Pine Script is the primary language for alert condition logic. Python handles everything downstream: relay servers, data analysis, A/B testing pipelines, and execution if needed. This two-language stack covers 95% of what a serious individual trader needs. The remaining 5% — ultra-low-latency execution, institutional data pipelines — requires C++ or Rust, and is out of scope for the alert systems described in this guide.
Pine Script is purpose-built for TradingView. It evaluates on every candle close (or on every tick in real-time mode), has access to all built-in indicators, and can publish plots that become webhook payload values. Its limitations: no external API calls, no persistent state across sessions (you can use var for within-session state), and execution is sandboxed to TradingView. For alert logic, these limitations are irrelevant.
A complete Pine Script alert template for multi-condition breakout detection:
//@version=5
indicator("Multi-Condition Breakout Alert", overlay=true)
// --- Inputs ---
ema_length = input.int(200, "EMA Length")
rsi_length = input.int(14, "RSI Length")
rsi_threshold = input.float(50, "RSI Threshold")
vol_multiplier = input.float(1.5, "Volume Multiplier (vs 20D avg)")
// --- Calculations ---
ema200 = ta.ema(close, ema_length)
rsi = ta.rsi(close, rsi_length)
vol_avg = ta.sma(volume, 20)
vol_ratio = volume / vol_avg
// --- Conditions ---
above_ema = close > ema200
rsi_crossed_50 = ta.crossover(rsi, rsi_threshold)
vol_surge = vol_ratio > vol_multiplier
// --- Alert condition: all three must be true ---
breakout_signal = above_ema and rsi_crossed_50 and vol_surge
// --- Plot for webhook payload ---
plot(vol_ratio, "Vol Ratio", display=display.none)
plot(rsi, "RSI", display=display.none)
// --- Alert ---
alertcondition(breakout_signal, "Breakout Signal",
"BREAKOUT|{{ticker}}|{{close}}|{{plot_0}}|{{plot_1}}|{{time}}")
Python handles the relay, parsing, and logging. When you use a structured alert message format (pipe-delimited in the example above), parsing is trivial:
def parse_alert(raw_message):
parts = raw_message.split("|")
return {
"type": parts[0],
"symbol": parts[1],
"price": float(parts[2]),
"vol_ratio": float(parts[3]),
"rsi": float(parts[4]),
"time": parts[5]
}
This structured format enables automated logging to a CSV or SQLite database — every alert gets a row with all context values. After 30 days, you have a dataset to evaluate alert quality: which alerts were followed by a valid 1% move in the intended direction within 4 hours, which fired at noise, what the average vol_ratio was at true positives versus false positives.
JavaScript/Node.js is an alternative for the relay server if you prefer it, and it works well with Discord's webhook API. For teams already running Node.js infrastructure, the implementation is straightforward. Python has more mature data analysis libraries (pandas, sqlite3) for the A/B testing analysis layer, so the tradeoff is relay convenience versus analysis convenience.
Bash deserves mention for simple setups. If you only need TradingView → email → SMS and don't want to run a server, the entire relay can be a bash script called by a cron job that checks a Gmail label for new alert emails and forwards them via Pushover. This is slower (email latency adds 30–120 seconds) and is only appropriate for informational Level 3 alerts where immediate action is never required.
Do not use Jupyter notebooks for any component that runs in production. Notebooks are for analysis and debugging. Production relay servers need to be scripts with logging, error handling, and service management. A notebook that you leave running in a terminal is one kernel crash away from a silent alert failure.
For funding rate and liquidation cascade alerts, you need data that TradingView does not natively surface. The solution is a Python script that polls exchange APIs (Bybit, Binance) and writes to a local data store that TradingView can read via a custom data feed, or alternatively runs its own alerting logic independently of TradingView. This is covered in Chapter 5 with complete code.
Single-indicator alerts are the source of most false positives. The RSI crossing 70 on a 15-minute BTC chart fires dozens of times per day. Most of them go nowhere. Adding a second condition — require the price to also be above the 200 EMA — cuts the noise by roughly half. Adding a third — require volume to be elevated — cuts it further. The goal is a confirmation gate that each condition must pass before the alert fires.
Four-condition breakout alert (complete Pine Script):
//@version=5
indicator("Vault Breakout Detector v2", overlay=true)
// Inputs
swing_lookback = input.int(20, "Swing High Lookback")
ema_fast = input.int(50, "Fast EMA")
ema_slow = input.int(200, "Slow EMA")
rsi_len = input.int(14, "RSI Length")
vol_lookback = input.int(20, "Volume Average Lookback")
vol_mult = input.float(1.5, "Min Volume Multiplier")
atr_len = input.int(14, "ATR Length")
// Calculations
fast_ema = ta.ema(close, ema_fast)
slow_ema = ta.ema(close, ema_slow)
rsi_val = ta.rsi(close, rsi_len)
vol_avg = ta.sma(volume, vol_lookback)
vol_ratio = volume / vol_avg
atr = ta.atr(atr_len)
swing_high = ta.highest(high, swing_lookback)[1]
// Conditions
price_above_slow_ema = close > slow_ema
ema_alignment = fast_ema > slow_ema
breakout_candle = close > swing_high
rsi_momentum = rsi_val > 50 and rsi_val < 75 // avoid already-overbought entries
volume_confirmed = vol_ratio >= vol_mult
// Gate: require all 5 conditions
full_signal = price_above_slow_ema and ema_alignment and breakout_candle
and rsi_momentum and volume_confirmed
// Level 2: 3 of 5 conditions — note the setup forming
partial_signal = (price_above_slow_ema ? 1 : 0) + (ema_alignment ? 1 : 0) +
(breakout_candle ? 1 : 0) + (rsi_momentum ? 1 : 0) +
(volume_confirmed ? 1 : 0) >= 3 and not full_signal
// Plots for webhook payload
plot(vol_ratio, "VolRatio", display=display.none)
plot(rsi_val, "RSI", display=display.none)
plot(atr, "ATR", display=display.none)
// Alerts
alertcondition(full_signal, "L1 Breakout",
"L1|BREAKOUT|{{ticker}}|{{close}}|{{plot_0}}|{{plot_1}}|{{plot_2}}|{{time}}")
alertcondition(partial_signal, "L2 Breakout Setup",
"L2|BREAKOUT_SETUP|{{ticker}}|{{close}}|{{plot_0}}|{{plot_1}}|{{plot_2}}|{{time}}")
Support/resistance alert with rejection confirmation:
//@version=5
indicator("S/R Touch Alert", overlay=true)
// Key levels — update these manually or use a pivot calculation
sr_level = input.float(43500, "Key S/R Level")
proximity_pct = input.float(0.3, "Proximity % to Level")
rsi_len = input.int(14, "RSI Length")
vol_lookback = input.int(20, "Vol Average Lookback")
// Calculations
rsi_val = ta.rsi(close, rsi_len)
vol_avg = ta.sma(volume, vol_lookback)
vol_ratio = volume / vol_avg
proximity_range = sr_level * (proximity_pct / 100)
near_level = math.abs(close - sr_level) <= proximity_range
// Rejection pattern: wick to level, close away
upper_wick = high - math.max(open, close)
lower_wick = math.min(open, close) - low
rejection_at_resistance = near_level and upper_wick > (high - low) * 0.5
rejection_at_support = near_level and lower_wick > (high - low) * 0.5
// Confirm with RSI diverging from level
rsi_overbought_at_res = rsi_val > 65 and rejection_at_resistance
rsi_oversold_at_sup = rsi_val < 35 and rejection_at_support
// Volume spike confirms institutional activity
vol_confirm = vol_ratio > 1.3
res_rejection_signal = rsi_overbought_at_res and vol_confirm
sup_bounce_signal = rsi_oversold_at_sup and vol_confirm
plot(rsi_val, "RSI", display=display.none)
plot(vol_ratio, "VolRatio", display=display.none)
alertcondition(res_rejection_signal, "Resistance Rejection",
"L1|RES_REJECT|{{ticker}}|{{close}}|{{plot_0}}|{{plot_1}}|{{time}}")
alertcondition(sup_bounce_signal, "Support Bounce",
"L1|SUP_BOUNCE|{{ticker}}|{{close}}|{{plot_0}}|{{plot_1}}|{{time}}")
Alert fatigue reduction — the 3-condition requirement:
The standard for Level 1 classification in this system is three independent confirmations from different signal categories. "Independent" means the conditions should not be mathematically derived from each other: RSI and MACD are not independent (both derive from price momentum). RSI and volume ratio are independent. Price relative to EMA and volume are independent. RSI and funding rate are independent.
Pairs that are independent and commonly combined:
The plot + {{plot_N}} pattern is essential for rich alert payloads. Without it, you get only price and time. With it, you get all the context values at the moment of trigger, which is what you need to evaluate the alert without opening a chart.
News-driven alerts work differently from technical alerts. The latency requirements are different (seconds, not milliseconds), the signal format is unstructured text, and the false positive rate is high because news headlines frequently do not move markets the way they appear to predict. The operational approach is to use news alerts as a market context layer that modifies how you evaluate technical alerts — not as standalone entry signals.
The practical workflow: news arrives via a fast data source, is classified by type, and is used to either suppress or elevate pending technical alerts. If a Level 2 technical breakout alert is forming and a macro risk-off headline fires (Fed hawkish surprise, major exchange hack, regulatory action), you suppress the Level 2 from upgrading to Level 1. If a positive catalyst fires (ETF approval news, major protocol upgrade), a Level 2 setup that was borderline gets flagged for manual review.
Data sources by latency tier:
Sub-5 second: Crypto-specific APIs — Kaiko's news feed, CryptoPanic API, Messari's real-time API. These are paid services ($50–500/month). CryptoPanic has a free tier limited to 10 requests/minute, sufficient for a personal setup if polled every 30 seconds.
5–30 second: Twitter/X API (Premium tier required for real-time stream). Set up a filtered stream for keywords: "SEC", "hack", "exploit", "emergency", "Federal Reserve", your specific holding tickers. This is the most useful news source for crypto trading — regulatory and security events move markets hardest and fastest.
1–5 minute: RSS feeds from The Block, CoinDesk, Decrypt. Free and easy to parse. Useful for confirmation and context, not for immediate action.
CryptoPanic API integration for real-time news classification:
import requests
import time
CRYPTOPANIC_API = "https://cryptopanic.com/api/v1/posts/"
API_KEY = "YOUR_KEY"
def get_latest_news(currencies=None, filter_type="important"):
params = {
"auth_token": API_KEY,
"filter": filter_type, # "important", "hot", "bullish", "bearish"
"currencies": currencies or "BTC,ETH",
}
resp = requests.get(CRYPTOPANIC_API, params=params, timeout=5)
if resp.status_code != 200:
return []
return resp.json().get("results", [])
def classify_news(article):
title = article.get("title", "").lower()
votes = article.get("votes", {})
# Negative signals
if any(w in title for w in ["hack", "exploit", "stolen", "breach", "ban", "illegal"]):
return "RISK_OFF_SEVERE"
if votes.get("negative", 0) > votes.get("positive", 0) * 1.5:
return "RISK_OFF_MODERATE"
# Positive signals
if any(w in title for w in ["approved", "etf", "institutional", "partnership"]):
return "RISK_ON_MODERATE"
return "NEUTRAL"
# Poll every 60 seconds and send classified alerts to Telegram
def news_monitor_loop(send_fn):
seen_ids = set()
while True:
articles = get_latest_news()
for article in articles:
if article["id"] in seen_ids:
continue
seen_ids.add(article["id"])
classification = classify_news(article)
if classification != "NEUTRAL":
msg = f"📰 <b>{classification}</b>\n{article['title']}\n{article.get('url', '')}"
send_fn(msg)
time.sleep(60)
Economic event calendar integration:
For macro events (FOMC, CPI, NFP), use a pre-loaded calendar rather than real-time parsing. These events are known days or weeks in advance. The alert fires before the event, not after: "MACRO EVENT IN 15 MINUTES: FOMC Rate Decision. Elevated volatility expected. Review open positions."
import json
from datetime import datetime, timezone
# events.json — manually updated monthly
# [{"name": "FOMC Rate Decision", "time": "2026-06-11T18:00:00Z", "impact": "HIGH"}]
def check_upcoming_events(events_file, lookahead_minutes=15):
with open(events_file) as f:
events = json.load(f)
now = datetime.now(timezone.utc)
alerts = []
for event in events:
event_time = datetime.fromisoformat(event["time"])
delta = (event_time - now).total_seconds() / 60
if 0 < delta <= lookahead_minutes:
alerts.append(event)
return alerts
The pre-event alert fires 15 minutes before any high-impact macro event and automatically suppresses all Level 1 technical alerts for 30 minutes centered on the event time. The logic: fundamental data releases create non-technical price movements. A breakout that fires 5 minutes before FOMC is not a breakout — it's pre-release volatility. Suppressing Level 1 alerts during these windows reduces false entry signals significantly.
The connection between alert receipt and position entry is where most manual alert systems break down. You get the notification, open the exchange, and find the price has moved 0.8% since the alert fired. For Level 1 setups with tight entry requirements, that slippage can invalidate the entire risk/reward.
Semi-automated execution solves this: the alert relay server places a limit order at the alert price the moment the webhook fires. You receive the Telegram notification and a matching limit order is already sitting on the exchange. You confirm or cancel it — you never chase.
Bybit API order placement via ccxt (Level 1 auto-limit template):
import ccxt
import json
exchange = ccxt.bybit({
'apiKey': 'YOUR_API_KEY',
'secret': 'YOUR_SECRET',
'options': {'defaultType': 'linear'}, # USDT perps
})
def place_alert_limit(alert_data):
symbol = alert_data["symbol"] + "/USDT:USDT"
price = alert_data["price"]
atr = alert_data.get("atr", 0)
# Position sizing: risk 0.5% of account per trade
balance = exchange.fetch_balance()["USDT"]["free"]
risk_amount = balance * 0.005
stop_distance = atr * 1.5 # stop at 1.5x ATR below entry
if stop_distance == 0:
return None
position_size = risk_amount / stop_distance
position_size = round(position_size, 3)
# Place the limit order
order = exchange.create_order(
symbol=symbol,
type='limit',
side='buy',
amount=position_size,
price=price,
params={'timeInForce': 'PostOnly', 'reduceOnly': False}
)
# Immediately place stop loss
stop_price = price - stop_distance
exchange.create_order(
symbol=symbol,
type='stop_market',
side='sell',
amount=position_size,
params={'stopPrice': stop_price, 'reduceOnly': True}
)
return order
Rate limiting and error handling for execution relays:
Exchange APIs enforce request rate limits. Bybit's default is 10 requests per second for order placement. At normal alert volumes this is not a constraint. But during high-volatility events when multiple alerts fire simultaneously, you need a queue:
import queue
import threading
import time
order_queue = queue.Queue()
def order_worker():
while True:
order_data = order_queue.get()
try:
result = place_alert_limit(order_data)
log_order(result)
except ccxt.RateLimitExceeded:
time.sleep(1)
order_queue.put(order_data) # re-queue
except ccxt.InsufficientFunds as e:
send_telegram(f"⚠️ INSUFFICIENT FUNDS: {e}")
except Exception as e:
send_telegram(f"⚠️ ORDER ERROR: {e}")
finally:
order_queue.task_done()
time.sleep(0.1) # 100ms minimum spacing
worker_thread = threading.Thread(target=order_worker, daemon=True)
worker_thread.start()
API credential security:
Never hardcode credentials in scripts. Use environment variables:
import os
exchange = ccxt.bybit({
'apiKey': os.environ['BYBIT_API_KEY'],
'secret': os.environ['BYBIT_SECRET'],
})
On the VPS, store credentials in /etc/environment or use a .env file loaded by python-dotenv. Restrict API key permissions to trade and read-only — never enable withdrawal permissions on keys used by automated systems. Create a separate key for the relay server. Rotate keys quarterly.
Testing the execution pipeline before going live:
Use testnet environments. Bybit's testnet is at testnet.bybit.com — ccxt supports it via exchange.set_sandbox_mode(True). Run the full pipeline in testnet for 2 weeks minimum before live execution. Test specifically: alert fires → relay receives → order placed → stop loss placed → order confirmation message received in Telegram. Any break in this chain should surface in testnet, not in a live Level 1 setup.
Risk management in an automated alert system has two distinct layers: the risk rules encoded at design time (position sizing, stop placement, maximum daily loss) and the real-time monitoring that enforces those rules when the system is live. Most failures occur when these layers are inconsistent — the design says "risk 1% per trade" but the execution layer has no mechanism to enforce that, so a sequence of correlated losses exceeds the intended drawdown.
ATR-based stop placement (the only stop method that scales across volatility regimes):
Fixed-dollar stops fail during high-volatility periods — a $200 stop on BTC that is appropriate during low-volatility gets stopped out constantly during a high-volatility regime. ATR-based stops automatically adjust to the current volatility environment:
// In Pine Script — plot for webhook payload
atr14 = ta.atr(14)
stop_distance_long = close - (atr14 * 1.5)
stop_distance_short = close + (atr14 * 1.5)
tp1 = close + (atr14 * 2.5) // 1.67:1 reward/risk
tp2 = close + (atr14 * 4.0) // 2.67:1 reward/risk
plot(atr14, "ATR", display=display.none)
plot(stop_distance_long, "StopLong", display=display.none)
plot(tp1, "TP1", display=display.none)
The alert payload then carries the specific stop and target levels: {{close}}|{{plot_0}}|{{plot_1}}|{{plot_2}} — ATR, stop distance, TP1. The relay uses these directly for order placement.
Position sizing formula — fixed fractional risk:
def calculate_position_size(account_balance, risk_pct, entry_price, stop_price):
risk_dollars = account_balance * (risk_pct / 100)
stop_distance = abs(entry_price - stop_price)
if stop_distance == 0:
return 0
contracts = risk_dollars / stop_distance
return round(contracts, 4)
# Example: $50,000 account, 0.5% risk, BTC entry $45,000, stop $44,100
# Risk = $250, stop distance = $900, contracts = 0.2778 BTC
size = calculate_position_size(50000, 0.5, 45000, 44100) # → 0.2778
Maximum daily loss enforcement:
MAX_DAILY_LOSS_PCT = 2.0 # 2% of account
daily_pnl = 0.0 # reset at UTC midnight
def can_take_trade(current_balance, starting_balance):
loss_so_far = starting_balance - current_balance
loss_pct = (loss_so_far / starting_balance) * 100
if loss_pct >= MAX_DAILY_LOSS_PCT:
send_telegram("⛔ DAILY LOSS LIMIT REACHED. No new positions until UTC midnight.")
return False
return True
Correlation risk — the invisible layer:
Running simultaneous BTC long, ETH long, and SOL long alerts is not three independent positions. In risk-off events, all three decline together. Treat correlated positions as a single position for risk sizing. The rule: at any given time, total notional exposure to highly-correlated assets (correlation > 0.8 over 30 days) should not exceed 2x the per-trade risk. If your per-trade risk is 0.5%, simultaneous correlated positions should total no more than 1% risk.
Alert-triggered stop adjustment (trailing stops via relay):
def update_trailing_stop(symbol, current_price, entry_price, atr, trail_multiplier=2.0):
# Only trail if we're at least 1 ATR in profit
if current_price <= entry_price + atr:
return
new_stop = current_price - (atr * trail_multiplier)
# Cancel existing stop, place new one
open_orders = exchange.fetch_open_orders(symbol)
for order in open_orders:
if order.get("reduceOnly") and order["side"] == "sell":
exchange.cancel_order(order["id"], symbol)
exchange.create_order(
symbol=symbol,
type='stop_market',
side='sell',
amount=current_position_size,
params={'stopPrice': new_stop, 'reduceOnly': True}
)
This function is called from a secondary TradingView alert set to trigger when price moves 1 ATR above entry — the trailing stop alert fires a webhook that adjusts the stop on the exchange.
Multi-asset alert systems require explicit prioritization rules. You cannot act on 8 simultaneous Level 1 alerts across 8 pairs. The prioritization matrix determines which alert gets resources when multiple fire at once.
Asset priority stack (example configuration):
When multiple Level 1 alerts fire simultaneously, work down the priority stack. Do not open positions 3 and 4 if 1 and 2 are already consuming your daily risk budget.
BTC breakout full alert configuration:
Alert fires only if: price closes above the 20-period swing high AND EMA(50) > EMA(200) AND RSI(14) crossed above 50 in the last 3 bars AND volume is > 1.5x 20-day average AND price is not within 2 hours of a scheduled high-impact macro event.
//@version=5
indicator("BTC Breakout System", overlay=true)
// Trend filter
ema50 = ta.ema(close, 50)
ema200 = ta.ema(close, 200)
trend_up = ema50 > ema200
// Momentum filter
rsi = ta.rsi(close, 14)
rsi_crossed = ta.crossover(rsi, 50) or (rsi > 50 and rsi[1] > 50 and rsi[2] < 50)
// Structure break
swing_high = ta.highest(high, 20)[1]
structure_break = close > swing_high
// Volume confirmation
vol_ratio = volume / ta.sma(volume, 20)
vol_ok = vol_ratio > 1.5
// Time filter — avoid 30 min before major closes (optional)
not_weekend = dayofweek != dayofweek.saturday and dayofweek != dayofweek.sunday
// Final gate
signal = trend_up and rsi_crossed and structure_break and vol_ok and not_weekend
plot(vol_ratio, "VolRatio", display=display.none)
plot(rsi, "RSI", display=display.none)
plot(swing_high, "SwingHigh", display=display.none)
alertcondition(signal, "BTC Breakout L1",
"L1|BTC_BREAKOUT|{{ticker}}|{{close}}|{{plot_0}}|{{plot_1}}|{{plot_2}}|{{time}}")
ETH/BTC ratio alert for rotation signals:
When ETH is outperforming BTC (ratio rising), alt exposure gets a tailwind. When ETH is underperforming (ratio falling), alt longs face headwinds regardless of their individual setup quality.
//@version=5
indicator("ETH/BTC Ratio Alert", overlay=true)
ethbtc = request.security("ETHBTC", timeframe.period, close)
ethbtc_ema = ta.ema(ethbtc, 20)
ratio_rising = ta.crossover(ethbtc, ethbtc_ema)
ratio_falling = ta.crossunder(ethbtc, ethbtc_ema)
alertcondition(ratio_rising, "ETH/BTC Rising", "L3|ETHBTC_UP|{{close}}|{{time}}")
alertcondition(ratio_falling, "ETH/BTC Falling", "L3|ETHBTC_DOWN|{{close}}|{{time}}")
Liquidation cascade detection:
This requires exchange liquidation data, which TradingView does not expose natively. Use Bybit's WebSocket liquidation stream directly:
import websockets
import asyncio
import json
BYBIT_WS = "wss://stream.bybit.com/v5/public/linear"
async def liquidation_monitor(send_fn):
async with websockets.connect(BYBIT_WS) as ws:
await ws.send(json.dumps({
"op": "subscribe",
"args": ["liquidation.BTCUSDT", "liquidation.ETHUSDT"]
}))
cascade_window = []
while True:
msg = await ws.recv()
data = json.loads(msg)
if data.get("topic", "").startswith("liquidation"):
liq = data["data"]
cascade_window.append({
"size": float(liq["size"]),
"side": liq["side"],
"time": liq["updatedTime"]
})
# Rolling 60-second window
current_time = int(liq["updatedTime"])
cascade_window = [l for l in cascade_window
if current_time - int(l["time"]) < 60000]
total_liq = sum(l["size"] for l in cascade_window)
# Alert if >$5M liquidated in 60 seconds
if total_liq > 5_000_000:
side = max(set([l["side"] for l in cascade_window]),
key=lambda s: sum(l["size"] for l in cascade_window if l["side"] == s))
send_fn(f"🔴 L1|LIQUIDATION_CASCADE\nSide: {side}\nTotal: ${total_liq:,.0f} in 60s")
Alert system backtesting is not strategy backtesting. You are not testing whether a trading strategy is profitable — you are testing whether your alert conditions correctly identify setups that, historically, were worth evaluating. The metric is not P&L. It is precision (what fraction of alerts preceded a valid setup within N bars) and recall (what fraction of valid setups were caught by an alert).
Alert backtesting framework in Pine Script:
Pine Script's strategy() function backtest engine can be repurposed to evaluate alert quality. Replace the strategy's entry/exit logic with your alert conditions and measure outcomes:
//@version=5
strategy("Alert Backtest", overlay=true, initial_capital=100000)
// Alert conditions (same as your live alert)
ema50 = ta.ema(close, 50)
ema200 = ta.ema(close, 200)
rsi = ta.rsi(close, 14)
vol_ratio = volume / ta.sma(volume, 20)
signal = ema50 > ema200 and ta.crossover(rsi, 50) and vol_ratio > 1.5
// "Enter" on alert, "exit" after N bars to measure outcome
if signal
strategy.entry("Test", strategy.long)
// Exit after 12 bars (12 x 4H = 2 days)
if strategy.position_size > 0 and bar_index - strategy.opentrades.entry_bar_index(0) >= 12
strategy.close("Test")
This tells you, for every alert that would have fired: what was the price 12 bars later? The Strategy Tester tab shows the distribution of outcomes. A good alert configuration shows positive expectation (average trade > 0) and a win rate above 50% before any risk management is applied.
Python-based offline backtesting using logged alert data:
After 30+ days of live operation, your relay server has a log of every alert with context values. Use this to build a lookup table against historical price data:
import pandas as pd
import sqlite3
# Load alert log
conn = sqlite3.connect("alerts.db")
alerts = pd.read_sql("SELECT * FROM alerts WHERE type='L1'", conn)
# Load price data (from exchange API or CSV export)
prices = pd.read_csv("btc_4h.csv", parse_dates=["time"])
prices.set_index("time", inplace=True)
results = []
for _, alert in alerts.iterrows():
alert_time = pd.to_datetime(alert["timestamp"])
future_bars = prices[prices.index > alert_time].head(12)
if len(future_bars) < 12:
continue
entry_price = alert["price"]
max_high = future_bars["high"].max()
min_low = future_bars["low"].min()
close_12 = future_bars.iloc[-1]["close"]
# Did price reach 2% gain before 1.5% loss?
hit_tp = max_high >= entry_price * 1.02
hit_sl = min_low <= entry_price * 0.985
first_hit = "tp" if (future_bars[future_bars["high"] >= entry_price * 1.02].index.min()
< future_bars[future_bars["low"] <= entry_price * 0.985].index.min()) else "sl"
results.append({
"alert_time": alert_time,
"vol_ratio": alert["vol_ratio"],
"rsi": alert["rsi"],
"outcome": first_hit,
"close_change_pct": ((close_12 - entry_price) / entry_price) * 100
})
df = pd.DataFrame(results)
print(f"Win rate: {(df['outcome']=='tp').mean():.1%}")
print(f"Avg vol_ratio on wins: {df[df['outcome']=='tp']['vol_ratio'].mean():.2f}")
print(f"Avg vol_ratio on losses: {df[df['outcome']=='sl']['vol_ratio'].mean():.2f}")
This analysis typically reveals the optimal vol_ratio threshold. If wins average 1.8x volume and losses average 1.4x, raising the threshold from 1.5x to 1.7x should improve precision without sacrificing too much recall.
A/B test configuration:
Run two alert configurations simultaneously for 30 days. Configuration A on BTC, Configuration B on ETH. After 30 days, calculate precision for both. Rotate the better configuration to both pairs for the next 30 days. This continuous improvement loop is how the system adapts to changing market structure without requiring a full rebuild.
Real-time monitoring for an automated alert system has two components: monitoring that the alert infrastructure is functioning (delivery pipeline health) and monitoring open positions that were entered on alerts (trade health). Most traders address the second and ignore the first, which leads to silent failures where alerts stop delivering and the trader assumes nothing is happening.
Infrastructure health monitoring:
Set a heartbeat alert in TradingView — an alert that fires every 6 hours unconditionally. If you don't receive the heartbeat, the pipeline is broken.
//@version=5
indicator("Heartbeat", overlay=false)
// Fire every 6 hours (360 minutes) on the minute chart
is_heartbeat_bar = (hour == 0 or hour == 6 or hour == 12 or hour == 18) and minute == 0
alertcondition(is_heartbeat_bar, "Heartbeat", "HEARTBEAT|{{time}}")
In the relay, track heartbeat receipt and alert if one is missed:
import time
last_heartbeat = time.time()
HEARTBEAT_TIMEOUT = 6.5 * 3600 # 6.5 hours
def handle_heartbeat():
global last_heartbeat
last_heartbeat = time.time()
def heartbeat_watchdog(send_fn):
while True:
time.sleep(300) # check every 5 minutes
if time.time() - last_heartbeat > HEARTBEAT_TIMEOUT:
send_fn("⚠️ PIPELINE ALERT: No heartbeat received in 6+ hours. Check TradingView alerts.")
Open position monitoring dashboard:
For each position opened on an alert, the relay tracks entry price, stop price, ATR at entry, and time. A background thread checks positions against current price every 5 minutes and sends status updates for Level 1 positions:
def position_status_update(position, current_price):
entry = position["entry"]
stop = position["stop"]
tp1 = position["tp1"]
atr = position["atr"]
pnl_pct = ((current_price - entry) / entry) * 100
r_multiple = (current_price - entry) / (entry - stop)
status = f"""
📊 Position Update: {position['symbol']}
Entry: ${entry:,.2f}
Current: ${current_price:,.2f}
PnL: {pnl_pct:+.2f}%
R-Multiple: {r_multiple:.2f}R
Stop: ${stop:,.2f}
TP1: ${tp1:,.2f}
"""
return status
Pre-defined response rules for alerts that fire outside active hours:
The 3am problem requires pre-defined rules, not real-time decisions. Document these before your system goes live:
Store these rules in a configuration file, not in code, so they can be updated without redeployment:
{
"overnight_hours_utc": [0, 6],
"rules": {
"BTC_BREAKOUT": {"overnight_action": "half_size_limit", "expiry_hours": 2},
"SUP_BOUNCE": {"overnight_action": "none", "downgrade_to": "L2"},
"LIQUIDATION_CASCADE_SHORT": {"overnight_action": "limit_3pct_below"},
"MACRO_EVENT_WINDOW": {"action": "suppress_L1", "notify_only": true}
}
}
Multi-platform synchronization — routing the same alert to TradingView for charting, Telegram for notification, Discord for community sharing, and an execution relay for position management — requires a message broker architecture. The naive approach (one TradingView alert URL per destination) breaks because TradingView only sends to one webhook URL per alert. The correct approach is a single relay endpoint that fans out to all destinations based on alert tier.
Fan-out relay architecture:
import json
import threading
ROUTING_CONFIG = {
"L1": {
"telegram_channels": ["-100PERSONAL_CHAT", "-100TEAM_CHAT"],
"discord_webhooks": ["https://discord.com/api/webhooks/..."],
"execute_order": True,
"log_to_db": True,
},
"L2": {
"telegram_channels": ["-100PERSONAL_CHAT"],
"discord_webhooks": [],
"execute_order": False,
"log_to_db": True,
},
"L3": {
"telegram_channels": [],
"discord_webhooks": [],
"execute_order": False,
"log_to_db": True,
},
"HEARTBEAT": {
"telegram_channels": [],
"discord_webhooks": [],
"execute_order": False,
"log_to_db": False,
}
}
def route_alert(payload):
alert_type = payload.get("type", "L3")
config = ROUTING_CONFIG.get(alert_type, ROUTING_CONFIG["L3"])
threads = []
for chat_id in config["telegram_channels"]:
t = threading.Thread(target=send_telegram, args=(chat_id, format_telegram(payload)))
threads.append(t)
for webhook_url in config["discord_webhooks"]:
t = threading.Thread(target=send_discord, args=(webhook_url, format_discord(payload)))
threads.append(t)
if config["execute_order"]:
t = threading.Thread(target=place_alert_limit, args=(payload,))
threads.append(t)
if config["log_to_db"]:
log_alert_to_db(payload)
for t in threads:
t.start()
for t in threads:
t.join(timeout=5)
Multi-timeframe confirmation using two TradingView alerts:
A single Pine Script cannot check conditions across different timeframes in real-time alert mode (only the chart's current timeframe evaluates). The workaround is two separate alerts on two different chart timeframes, both webhooking to the relay. The relay holds a state record of recent alerts and only fires the fan-out when both timeframes have confirmed:
import time
from collections import defaultdict
# Pending confirmations: {symbol: {alert_type: {timeframe: timestamp}}}
pending = defaultdict(lambda: defaultdict(dict))
CONFIRMATION_WINDOW_SECONDS = 300 # both timeframes must confirm within 5 minutes
def handle_alert(payload):
symbol = payload["symbol"]
alert_type = payload["alert_type"]
timeframe = payload["timeframe"] # "1H" or "4H"
pending[symbol][alert_type][timeframe] = time.time()
# Check if both timeframes confirmed within window
tf_data = pending[symbol][alert_type]
if "1H" in tf_data and "4H" in tf_data:
age_1h = time.time() - tf_data["1H"]
age_4h = time.time() - tf_data["4H"]
if age_1h <= CONFIRMATION_WINDOW_SECONDS and age_4h <= CONFIRMATION_WINDOW_SECONDS:
# Multi-TF confirmed — upgrade to actionable
payload["type"] = "L1"
payload["confirmation"] = "MULTI_TF"
route_alert(payload)
del pending[symbol][alert_type] # clear after routing
Funding rate extreme alerts using exchange API (not TradingView):
TradingView does not carry funding rate data natively. Poll the exchange API directly:
import requests
import time
def get_funding_rate(symbol="BTCUSDT"):
url = f"https://api.bybit.com/v5/market/funding/history?category=linear&symbol={symbol}&limit=1"
resp = requests.get(url, timeout=5)
data = resp.json()
if data["retCode"] == 0:
return float(data["result"]["list"][0]["fundingRate"])
return None
def funding_rate_monitor(send_fn):
EXTREME_LONG = 0.0008 # 0.08% — market extremely long
EXTREME_SHORT = -0.0004 # -0.04% — market extremely short
while True:
for symbol in ["BTCUSDT", "ETHUSDT", "SOLUSDT"]:
rate = get_funding_rate(symbol)
if rate is None:
continue
if rate >= EXTREME_LONG:
send_fn(f"⚠️ L1|FUNDING_EXTREME_LONG\n{symbol}: {rate*100:.4f}%\nOverheated longs. Elevated squeeze risk.")
elif rate <= EXTREME_SHORT:
send_fn(f"⚠️ L1|FUNDING_EXTREME_SHORT\n{symbol}: {rate*100:.4f}%\nShort squeeze setup possible.")
time.sleep(3600) # check every hour
Security in a trading automation context is not abstract. There are specific attack surfaces: API keys on the relay server, webhook endpoints that accept unauthenticated POST requests, exchange accounts accessible from VPS IP addresses, and Telegram bots that respond to any user who knows the bot name.
API key security — specific controls:
Never store API keys in code or in a git repository. Use environment variables on the VPS. If you are using a cloud function (Lambda, Cloud Functions), use the provider's secrets manager — AWS Secrets Manager or Google Cloud Secret Manager. Rotate keys every 90 days. Create exchange API keys with minimum required permissions: for a relay that only places orders, enable "Trade" only — never enable "Withdraw."
Set IP allowlists on exchange API keys. Bybit, Binance, and OKX all support this. Restrict the API key to the VPS IP address only. If the VPS IP is compromised, the exchange key cannot be used from a different IP.
# Check your VPS IP
curl https://api.ipify.org
# Add to exchange API key settings: allow only THIS IP
# In Bybit: Account & Security → API Management → Edit Key → IP Access Restriction
Webhook endpoint security:
TradingView webhooks are unauthenticated by default — any party who knows your webhook URL can POST to it and potentially trigger order placement. Use a secret token in every payload and validate it on the relay:
import hmac
import hashlib
def validate_webhook(payload, received_signature, secret):
expected = hmac.new(
secret.encode(),
json.dumps(payload, sort_keys=True).encode(),
hashlib.sha256
).hexdigest()
return hmac.compare_digest(expected, received_signature)
Additionally, restrict your relay server's port 443 to accept connections only from TradingView's IP ranges. TradingView publishes their webhook source IPs — add them to your VPS firewall (ufw or iptables). Any request from outside those IPs is rejected before it reaches your application.
Telegram bot security:
Your Telegram bot should respond only to your specific chat ID. Any other user who messages the bot gets no response:
AUTHORIZED_CHAT_IDS = {-100YOUR_PERSONAL_CHAT, -100YOUR_TEAM_CHAT}
def handle_message(update):
chat_id = update["message"]["chat"]["id"]
if chat_id not in AUTHORIZED_CHAT_IDS:
return # silently ignore
# process command
VPS hardening checklist:
PermitRootLogin no in /etc/ssh/sshd_config)unattended-upgrades on Ubuntu)Incident response procedure:
If you suspect a compromise: immediately revoke all exchange API keys from the exchange UI (not from the compromised server). Transfer funds to a cold wallet if exchange accounts are at risk. Terminate the VPS instance. Create a new VPS from a clean image. Regenerate all credentials.
Keep a physical note (not digital, not stored on the VPS) with emergency access steps: exchange API key revocation URL, exchange withdrawal halt instructions, VPS provider emergency contact.
Scaling an alert system means handling more pairs, more timeframes, and more concurrent alert types without increasing noise or management overhead. The scaling principle is: add leverage to the infrastructure, not to the number of things you manually manage.
Pair expansion without proportional alert increase:
The naive approach to adding coverage — create a new TradingView alert for each new pair — fills your alert quota and floods your notification channels. The systematic approach is to build multi-pair scripts that evaluate all pairs in a single indicator and output a sorted signal list.
//@version=5
indicator("Multi-Pair Scanner", overlay=false)
// Evaluate up to 40 pairs using security() calls
// Show only the top 3 by signal strength
btc_close = request.security("BINANCE:BTCUSDT", "240", close)
eth_close = request.security("BINANCE:ETHUSDT", "240", close)
sol_close = request.security("BINANCE:SOLUSDT", "240", close)
bnb_close = request.security("BINANCE:BNBUSDT", "240", close)
btc_rsi = request.security("BINANCE:BTCUSDT", "240", ta.rsi(close, 14))
eth_rsi = request.security("BINANCE:ETHUSDT", "240", ta.rsi(close, 14))
btc_vol_ratio = request.security("BINANCE:BTCUSDT", "240",
volume / ta.sma(volume, 20))
eth_vol_ratio = request.security("BINANCE:ETHUSDT", "240",
volume / ta.sma(volume, 20))
// Signal: RSI crossed 50 AND vol > 1.5x
btc_sig = ta.crossover(btc_rsi, 50) and btc_vol_ratio > 1.5
eth_sig = ta.crossover(eth_rsi, 50) and eth_vol_ratio > 1.5
// Single alert covers both pairs
any_signal = btc_sig or eth_sig
signal_text = btc_sig ? "BTC" : eth_sig ? "ETH" : "NONE"
alertcondition(any_signal, "Multi-Pair L2",
"L2|MULTI_PAIR|" + signal_text + "|{{time}}")
Horizontal infrastructure scaling:
When alert volume genuinely grows (running 50+ pairs, serving a subscriber base), a single relay process is a single point of failure and a throughput bottleneck. The scaling pattern is to distribute the relay across multiple workers using a message queue:
# Producer: receives webhooks, puts to queue
import redis
r = redis.Redis(host='localhost', port=6379, db=0)
def webhook_handler(payload):
r.lpush("alert_queue", json.dumps(payload))
# Consumer workers (run multiple instances)
def alert_worker():
while True:
_, raw = r.brpop("alert_queue", timeout=5)
if raw:
payload = json.loads(raw)
route_alert(payload)
Redis as a queue allows you to run 2–5 worker processes consuming from the same queue. Any worker picks up the next alert. If one worker is handling an execution order (which takes 200–500ms), other workers continue processing informational alerts without delay.
Performance metrics to track:
Build a simple metrics dashboard. Track these weekly:
| Metric | Definition | Target | |---|---|---| | Alert precision | L1 alerts followed by valid setup within 12 bars | > 55% | | Delivery latency | TradingView condition-true to Telegram receipt | < 4 seconds | | Infrastructure uptime | Relay server uptime | > 99.5% | | Alert-to-action rate | L1 alerts that resulted in a position | > 40% | | False positive rate | L1 alerts where setup was invalid on review | < 25% |
Track these in a simple spreadsheet updated weekly from your relay logs. The trends matter more than the absolute numbers — a declining precision over a quarter signals that market conditions have shifted and the alert configuration needs retuning.
Subscriber management for paid alert services:
If you run a paid alert channel, the relay needs subscriber management: a list of authorized Telegram chat IDs, subscription status checks, and a mechanism to add/remove users without restarting the relay. Store subscriptions in a SQLite database and reload on each message routing:
def get_authorized_subscribers():
conn = sqlite3.connect("subscribers.db")
rows = conn.execute("SELECT chat_id FROM subscribers WHERE active=1 AND tier >= ?",
(required_tier,)).fetchall()
conn.close()
return [row[0] for row in rows]
Long-term operational discipline for an alert system requires three practices that most traders abandon within 90 days: systematic logging, periodic retuning, and documentation of response rules. Without logging, you have no data to retune from. Without retuning, the system's precision degrades as market structure changes. Without documented response rules, you revert to ad-hoc decision-making under pressure.
The monthly review process:
On the last day of each month, run this analysis against your alert log:
def monthly_review(db_path, price_data_path):
conn = sqlite3.connect(db_path)
month_ago = datetime.now() - timedelta(days=30)
alerts = pd.read_sql(
"SELECT * FROM alerts WHERE timestamp > ? AND type='L1'",
conn,
params=[month_ago.isoformat()]
)
prices = pd.read_csv(price_data_path, parse_dates=["time"])
# For each alert, classify outcome
outcomes = []
for _, alert in alerts.iterrows():
outcome = classify_alert_outcome(alert, prices)
outcomes.append(outcome)
df = pd.DataFrame(outcomes)
report = f"""
=== MONTHLY ALERT REVIEW ===
Period: {month_ago.date()} to {datetime.now().date()}
L1 Alerts fired: {len(df)}
True positives (TP hit before SL): {(df['outcome']=='tp').sum()} ({(df['outcome']=='tp').mean():.1%})
False positives (SL hit before TP): {(df['outcome']=='sl').sum()} ({(df['outcome']=='sl').mean():.1%})
No fill (price never returned): {(df['outcome']=='no_fill').sum()}
Top performing condition combos:
{df.groupby('conditions')['outcome'].apply(lambda x: (x=='tp').mean()).sort_values(ascending=False).head(3)}
Recommended threshold adjustments:
Vol ratio current: {current_vol_threshold:.2f}
Optimal based on data: {df[df['outcome']=='tp']['vol_ratio'].quantile(0.25):.2f}
"""
return report
Alert configuration version control:
Treat your Pine Script alert configurations and relay routing rules as code. Store them in a git repository. Every time you make a threshold change, commit it with a note explaining why. After 6 months, you can diff configurations and correlate changes to precision improvements or degradations. This is the discipline that separates a tuned system from one that drifts.
# Minimal git workflow for alert config
git init alert-configs
git add btc_breakout_v3.pine funding_alert_v2.py routing_rules.json
git commit -m "Raise vol_ratio threshold from 1.5 to 1.7 — Jun review showed better precision at 1.7+"
The four failure modes and their remedies:
Alert fatigue: Too many L1 alerts, you start ignoring them. Remedy: raise thresholds until L1 averages no more than 5 per day. Reclassify borderline signals as L2.
Silent failure: Relay server down, no alerts delivered, you don't notice. Remedy: heartbeat monitoring (Chapter 11). Test the pipeline by triggering a test alert weekly.
Stale configuration: Market structure changed (e.g., vol regime shift), your 2021-era thresholds no longer work. Remedy: monthly precision tracking. If precision drops below 45% for two consecutive months, rebuild the alert logic from scratch using recent data.
Execution-alert mismatch: Alerts are good, but your response rules are poorly defined, leading to inconsistent execution. Remedy: write response rules as explicit if/else logic in a document. "If L1 fires during US session, place limit order at alert price with ATR-based stop. If L1 fires overnight, place limit order at 0.3% above alert price (avoid bad fills at illiquid levels), smaller size."
The compounding effect of systematic alert improvement:
An alert system that starts at 50% precision and improves to 65% through quarterly tuning does not just improve win rate — it changes your relationship to the system. At 50%, you second-guess every alert. At 65%, you trust the process. The operational value of a reliable alert system is not only the trades it catches — it is the cognitive load it removes, freeing you to focus on position management rather than setup identification.
The infrastructure described in this guide — Pine Script multi-condition logic, webhook relay with fan-out routing, tiered alert classification, pre-defined response rules, monthly precision reviews — is not a complex system. The individual components are straightforward. The discipline is in maintaining them: logging everything, reviewing monthly, adjusting thresholds based on data, and documenting the rules that govern your responses. That discipline, compounded over a year, is the actual edge.
You just read the full guide. Download the professionally formatted 22-page PDF — every framework, checklist, and reference table laid out for quick reference and offline use.