Manage notifications and Telegram or Discord alerts

Review the notification centre#

Click the top-bar bell or use the Notifications shortcut/command. The centre groups entries by local day and shows unread state, severity and origin. Use All, Trading, System or Alerts, then severity/origin filters to narrow the list. Mark all read applies to the current category. A repeated group can collapse similar messages; open it to inspect individual details.

Click an entry to mark it read and run its first available action. Hover/focus offers Mark read/unread. Keyboard navigation includes Up/Down, Enter, R for read state, 1–4 for categories and Escape to close. The footer reports desktop and Telegram/Discord setup; Messaging alerts… opens their settings.

Set desktop behavior#

Open Settings → Notifications. Each category can use Toast + bell, Bell only or Off. Configure fill/rejection sound and Show when AMM is in the background separately. The permission row shows whether operating-system notification access is allowed; request permission through the offered control where supported. Browser desktop notifications are unavailable in this implementation.

A suppressed toast can still leave a bell-history entry if configured that way. A recorded event does not prove an external message was delivered. Keep trading error categories visible enough to detect rejected orders and disconnected sessions; reducing visual interruption is a display choice, not a change to trade state.

Configure Telegram#

1. Open Settings → Messaging alerts and select Telegram.
2. Create a Telegram bot using the provider's bot-creation flow and enter its token in the masked token field.
3. Set the default chat ID for deliveries.
4. Add exact allowed chat IDs and, for optional replies, numeric allowed user IDs.
5. Enable the channel, resolve inline validation and Save.
6. Use Send test and inspect the result and last-sent/listener status.

The stored-token indicator lets you keep the existing secret without exposing it. Do not paste tokens or private account identifiers into public screenshots. Bot display names/usernames are not authorization identities; destination/user numeric IDs matter.

Configure Discord#

Create a Discord application/bot and enable the Message Content privileged intent in its provider settings. Invite it with access to the intended channel and permission to send messages, attach files and read message history. In Discord, enter the bot token, default channel ID and exact allowed channel/user IDs. Enable, validate and save, then send a test.

Allowed IDs are entered as chips; pasted lists are split/deduplicated. A wildcard user entry, where deliberately used, permits any qualifying non-bot sender inside an exactly allowed destination; it does not permit every chat or channel. Exact user IDs are preferable when a small known set of people should be authorized.

Bots run on the AMM API server and can continue while the desktop application is closed. Stopping that server stops its listener/delivery work. A channel status such as Configured, Starting or Connected has a distinct meaning; verify test delivery instead of treating stored settings as proof the provider accepted them.

Attach charts and enable replies deliberately#

Reply actions & charts controls Allow authorised reply actions, Allow actions on live accounts, Attach a chart by default, minimum chart bars and Action-code lifetime. Reply actions default off. Live-account actions are a separate high-risk opt-in that requires typing LIVE; enabling general replies does not enable live trading.

Actionable messages use generated one-time exact buttons/codes bound to the originating bot message and frozen target session. Use that button or reply with the complete exact code. AMM does not interpret general phrases such as “buy some gold”. The destination and sender must be allowed, the code unexpired/unclaimed and the target session still running with that action. A successful first claim, including IGNORE, consumes the alert; duplicates do not execute it again.

Default code lifetime is 24 hours, adjustable within the dialog's supported range. Choose a duration appropriate to the strategy/session context; an old alert is not necessarily a current market setup. Charts depict their configured capture context, not guaranteed execution prices.

Test without inferring live authority#

Use Send test for channel verification. A test involving trade-action buttons is accepted only for supported running Simulation or explicitly validated demo/test sessions with the required actions. Not every broker's paper account is an accepted interactive test target. A disabled test button explains the missing prerequisite; do not switch to a live target to bypass it.

Test messages are marked and are separate from actual condition confirmations/history. To test a background monitor's condition, inspect its completed-bar preview and history as well as delivery. A Telegram/Discord delivery can fail after a condition fires; the rule log/notification history records that outcome.

Diagnose delivery failure#

Check Enabled, stored token, destination, provider permissions, server reachability and listener status. Read the exact failed-delivery message. For replies, also check allowlists, originating message, expiry, session readiness and live-action policy. Saving a token does not grant broker permission or a missing venue entitlement.

Use notification history and Retry delivery where offered, rather than repeatedly editing a condition to generate duplicates. When requesting support, include the message time, channel, alert/rule identity and sanitized error. Exclude bot tokens and access tokens. Email in screener configuration is logging-only; it does not imply an SMTP mail service is configured.

Continue with related tasks#

Configure screener rules and background monitoring, Follow economic events and release history, Configure appearance, safety and saved preferences.