Alert types and thresholds

Alerts are how you let Tradient watch for setups in the background. You attach an alert to a saved scan, set a threshold, choose a delivery channel, and the runner takes over — checking the scan on a schedule and notifying you when conditions are met. This page documents every option.

The alert model

An alert is a row that points at a saved scan and carries four pieces of state:

• Frequency — how often the runner checks (realtime, daily, weekly).
• Threshold — the condition that has to be met for the alert to fire.
• Delivery — where the notification goes (email, webhook).
• Snapshot — the last result count and top score the runner observed, used to detect changes.

Frequencies

The runner wakes up every 5 minutes, looks for due alerts, and processes only the ones whose interval has elapsed since the last firing. You won’t get a daily alert at 3 a.m. followed by another at 9 a.m. — the cadence is enforced.

Threshold conditions

Any change

Fires whenever the result count differs from the last snapshot. Useful for “tell me when something appears or disappears in this scan,” but noisy if you have a large or volatile result set.

New results

Fires when the result count increases. Doesn’t fire when results disappear. This is the right default for scans where you only care about catching new opportunities.

Result count ≥ N

Fires when the result count crosses a numeric threshold. Use for “tell me when at least 5 setups are showing” — typically a regime indicator, since most days won’t produce 5 quality matches but unusual ones will.

The crossing semantics matter: this fires only when the count moves from below N to at-or-above N. Once it’s fired, it won’t fire again until the count drops back below N and crosses up a second time.

Top score ≥ N

Fires when the highest Tradient Score in the result set crosses a threshold. Use for “tell me when something truly excellent shows up” — set the bar at 75 or 80 and you’ll get a small handful per month, all of them worth a look.

Same crossing semantics as result count: fires on below→above transitions only.

Delivery channels

Email

Plain HTML email to the address on your account. Includes the scan name, result count, top result, and a deep link back to the saved scan in Radar. The fastest path from notification to acting on the trade.

Webhook

POST to a URL you control with a JSON payload describing the trigger. Use for routing alerts into Slack, Discord, a bot, or your own dashboard. See Webhooks reference for the exact payload schema.

Pausing and editing

Every alert has an active toggle. Inactive alerts are skipped by the runner but keep their snapshot, so when you re-enable them they pick up from the last known state rather than re-firing on the entire current result set.

Editing the threshold resets the snapshot — otherwise you could change “top score ≥ 70” to “top score ≥ 60” and never get notified because the previously-stored top score is already above the new threshold. The reset ensures the new threshold gets a fresh crossing check on the next sweep.

Best-practice patterns

• One alert per scan, never more.If you have two alerts on the same saved scan with different thresholds, you’ll get duplicate notifications. Use two saved scans instead.
• Use top-score alerts on broad scans. Combining a wide universe with a high score floor produces the best signal-to-noise.
• Use new-results alerts on narrow scans. A 5-ticker watchlist scan with new-results is essentially “tell me whenever any of these names becomes tradeable.”
• Use weekly frequency for regime checks. The market regime doesn’t change every 15 minutes. A weekly check is enough to catch the meaningful shifts.

Where to go next

• Watchlists — group tickers and scope alerts to them.
• Webhooks reference — integrate alerts into your own systems.