Configure screener rules and background monitoring

Choose the monitoring lifetime#

A Screener rule is checked while its screener session runs and can use the screen's rows/columns. A Background alert is a saved server-owned indicator monitor. It continues independently of open chart/screener views while the AMM server runs and recovers its saved state after server restart. Closing the desktop app is different from stopping the AMM server.

Use a screener rule for “notify when a row in this active comparison grid meets these column conditions”. Use a background alert for “monitor this exact instrument/timeframe/indicator even when I close its chart”. The row menu deliberately describes both choices. Neither is automatically an order or a profitable trading system.

View full-size screenshot ↗

Create a screener rule#

1. Open the screen's Rules, or right-click a row and choose Screener rule…; a group offers Screener rule for group….
2. Choose the target, such as all rows, one exact row or the supported group scope.
3. Configure the available operands/conditions and any cooldown/rearm behavior shown by the editor.
4. Select delivery channels. Verify Telegram/Discord configuration rather than assuming selection alone makes a bot usable.
5. Save/enable the rule and inspect its armed/fired state.
6. Use Rule log to review the firing and channel outcomes.

A one-row picker identifies the exact row with market/timeframe metadata. It does not add that instrument to Universe. If a rule references an indicator output, configure the same type, parameters and output column; a similarly named column is not necessarily the same input. When editing/removing columns, respect dependency warnings and recheck rules that might otherwise become always false.

Create a background indicator alert#

Open Background alerts → New alert, or choose Background alert for SYMBOL… from a screener/chart entry point. The editor has What to watch, When to alert and How to notify sections.

Choose the exact instrument and feed/account, then timeframe. Select a supported indicator/output and configure its parameters. Conditions can include supported direction/run behavior or numerical comparisons such as above, below or equal. Where the study offers positive/negative states, choose the actual state; Nova-specific Green/Red labels are not universal meanings for every indicator.

Set the required completed-bar run/consecutive count and review the preview where offered. Monitoring uses completed bars; the newest forming candle need not confirm the rule. Changing the condition resets its current run. Configure channels, optional chart attachment and destination overrides, then send a test notification and save. A marked test checks delivery; it is not a historic condition firing.

Create several monitors efficiently#

Use Multiple instruments… or Watch several instruments…. Add instruments from the exact feeds, choose supported timeframes in the matrix and inspect the count before continuing. Other… permits additional intervals where offered. Review the check stage's New, Already exist · skipped and Can't be created groups.

Resolve unavailable feeds or remove invalid rows before creating the batch. Existing matching identities are skipped rather than silently overwritten. A batch is useful for a diverse FX/index/metal watchlist, but every row still needs valid source history and its own indicator warmup. Do not multiply a one-minute demo test across live sources without reviewing each destination and delivery setting.

Manage monitoring and history#

The manager supports search/status filtering, grouping and selection. The alert detail has Overview, History and Settings. Menus offer Edit, Pause/Resume, Open chart, Duplicate, Send test and Archive. Archived entries can be restored or permanently deleted through explicit actions. Bulk selection offers appropriate common edits such as notifications and timeframe.

A paused alert is retained but does not continue normal monitoring. An archived alert is kept for recovery/history and is distinct from permanent deletion. History shows confirmations and per-channel delivery. Use Retry delivery where offered for a failed delivery rather than changing the indicator condition just to force another event. The new test action is marked and does not rewrite condition history.

Verify delivery and interactive actions#

The screener rule log and notification centre show failure details such as disabled notifications, missing channel setup or queue failure. A rule firing and a Telegram/Discord message being delivered are separate outcomes. Email is logging-only; no SMTP delivery service is supplied by that choice.

Messaging can optionally provide exact one-time reply buttons/codes for preconfigured session actions. This requires explicit reply policy, destination/user authorization and a still-valid target session. It does not interpret arbitrary natural-language trading requests. Live-account actions require their separate opt-in. An indicator alert with a chart image is not permission to execute every proposed trade.

Recover a waiting or failed alert#

Open its detail and inspect the reason: data unavailable, feed/account changed, catalog/indicator unavailable, warmup or delivery failure. Open Brokers & feeds, Change data feed… or Pause alert are offered where applicable. Fix the actual source dependency before resuming. Confirm the concrete market when the same ticker exists on several feeds. After restart, check the alert's current state and last completed bar; saved recovery does not promise reconstruction of every condition that occurred while its server was offline.

Continue with related tasks#

Build and use watchlists and screeners, Manage notifications and Telegram or Discord alerts, Add, configure and interpret chart indicators.