The way alerting fails is not that a message gets lost. It is that every message arrives through every channel with the same urgency, so within three weeks you have muted all of them, and the one notification a year that genuinely needed you inside ten minutes lands in a feed you stopped reading. More channels made this worse, not better.
The fix is boring and it works. Rank the events by what being late costs you, rank the channels by how hard they interrupt, and match them. Then never send anything else down the fast channel.
What the engine says it will deliver, and one discrepancy worth knowing
The deployments panel is where this is set up. At capture it showed an empty state under a heading reading DEPLOYED STRATEGIES, telling you to browse the backtested strategies and deploy them to receive live trading signals via webhook, email, Discord or Telegram.
The engine's feature list on the same page describes live deployments with real-time signal alerts via email, Discord and Telegram. So the two descriptions agree on three notification channels and the panel adds webhook, which is a different kind of thing and should be treated as one. A webhook is not a notification, it is a machine consumer. It exists so another piece of software can act on the signal without a human in the loop, and if you point it at a spreadsheet or a script you get a record without an interruption. That distinction turns out to be the most useful part of the setup.
I have not configured the routing form itself, so I am not going to tell you which per-event toggles exist. What follows is the assignment to make and the questions to answer when you open it.
Rank the events by what being late costs
Four event classes, and they are not equally urgent no matter how they feel at the time.
An entry signal on a daily strategy is the least urgent thing in the list, which surprises people. A 1day configuration produces a signal stamped at a candle boundary and you cannot act until your market is open anyway. Being ten minutes late costs approximately nothing. Being a day late costs the trade.
A fill confirmation is a record, not an event. You need it to exist and to be searchable. You do not need it to buzz.
A risk event is the only genuinely fast item: a stop level reached, a position moving hard against you, a strategy hitting the loss level where you said you would intervene. Minutes matter here, and this is the class that gets buried when everything else shares the channel.
An operational failure is also fast but in a different way. An order rejected, a connection dropped, a cap breached. It is not urgent because of the market, it is urgent because your automation has stopped being automation and you do not know it.
Give each channel exactly one job
Match the interruption cost of the channel to the latency requirement of the event, and be ruthless about the residual.
| Channel | Job | What it must never carry |
|---|---|---|
| Telegram | Risk events and operational failures only | Routine entry and exit signals |
| Discord | The searchable running log, one channel per strategy | Anything that needs you within the hour |
| The daily record and anything you will need in twelve months | Anything time-critical | |
| Webhook | Machine consumption, into your own sheet or script | Nothing, it does not interrupt |
Telegram is on your phone with push enabled, so it is the scarcest resource you have. Treat every message you route there as costing you a small amount of future attention, because it does. If the risk channel fires more than a handful of times a month you will start ignoring it, and at that point you have no alerting at all while believing you do.
Discord earns its place through structure rather than speed. Separate channels per strategy turn the feed into something you can actually reconstruct: when you want to know what a strategy did in March you scroll one channel rather than filtering a mixed stream. Turn off push for the whole server.
Email is the archive and the audit trail. It is the channel that still contains the record after you leave Discord or change phones, and it is searchable by ticker two tax years later. Filter it into a folder on arrival and read it on a schedule rather than on arrival.
Three rules that stop the assignment collapsing
Every routing scheme decays the same way, and it decays for these three reasons.
Nothing time-critical goes to a channel you also use socially. If your Telegram is where family messages arrive, your alerts sit in the same list as those and get swiped away with them. A separate account or a dedicated channel with a distinct notification sound is the whole fix and it takes ten minutes.
One event class per channel, and no duplication for comfort. Sending entry signals to all three because you are worried about missing them is precisely how you train yourself to ignore all three. Redundancy belongs in the delivery path, not in your attention.
Volume caps the design. Work out how many messages the setup will actually generate before you turn it on. The engine reports 350 trades backtested across 9 strategies, roughly 39 each. Nine deployed strategies at that pace is around 350 entries and exits a year across the book, close to one and a half messages per trading day, and that is only the signal class. Add fills, add operational events, and a single combined channel is a feed with several items a day that you will stop reading inside a month.
The failure that actually happens is silence
Everyone designs alerting for the message that arrives. The failure mode in practice is the message that does not, because a channel token expired, a bot got removed from a server, or a deployment was paused and nobody noticed.
Silence is indistinguishable from a quiet market, which is why it can run for weeks. So build one positive check rather than trusting absence. Once a day, at a fixed time, confirm three things: that at least one message arrived on some channel or that the day genuinely had no signals, that the deployment still appears in the deployed strategies panel, and that the open positions in your broker match what the signal history implies. That is a two minute check and it is the only one that catches a delivery path that has quietly stopped.
Then test the fast channel deliberately, once a month, by triggering something you expect to see. A path you have never tested is a path you are assuming, and the month you discover it was broken will be the month it mattered. Put the test on the same day you review your positions, so it is attached to a habit you already have rather than being one more thing to remember.