The channel field looks like a preference and it is actually a commitment. Choosing email says this can wait until I next open my inbox. Choosing a chat app on your phone says I am willing to be interrupted by this. Choosing a webhook says something I built will act on this without asking me. Most people pick whichever was already selected, then wonder why half their alerts arrive at the wrong urgency.
The rule I use is one sentence long. Pick the channel from the response time you can honestly deliver on that rule, not the response time the rule deserves. Those are different numbers and the second one is a fantasy.
What the four channels actually are
Start with what the module offers, because the vocabulary matters. The Alerts and Subscriptions page lists its channels as email, Discord, Telegram and webhook. There is no separate mobile push product in that list, which means push, in the sense of a buzz in your pocket a few seconds after the condition is true, is what you get when you route to Discord or Telegram and have that app's notifications enabled on your phone.
That reframing is useful rather than pedantic, because it tells you where the reliability actually lives. The urgency of a chat channel is not a property of the alert. It is a property of your phone settings, and it survives exactly as long as you leave those settings alone. An alert routed to Telegram on a phone in do not disturb is an email with extra steps.
Email is the opposite and its weaknesses are honest ones. It has no acknowledgement, no escalation and no concept of whether you were awake. It is also the only channel with a decent search history and a natural place to keep a record, which makes it genuinely good at the thing it is good at: rules whose value is cumulative rather than immediate.
A webhook is not a notification at all. It is a message to a program. Nothing about it reaches a human unless you wrote the part that does.
Three questions that settle it in twenty seconds
Ask these in order, per rule, at the moment you create it. The order matters because the first no ends the process.
First: if this fires and I see it forty five minutes later, have I lost anything? If the answer is no, the channel is email and you are done. A large share of rules land here and routing them to a phone is where fatigue starts. A valuation screen crossing a threshold, a filing appearing, a weekly condition, none of these need to interrupt you.
Second: if it fires at three in the morning, will I act? Be honest, and answer as the person you were last Tuesday rather than as the person you intend to become. If you will not act, the alert should not be capable of waking you, because a notification that wakes you and gets ignored is training you to ignore the ones that matter. Route it to a chat channel with the app's own quiet hours doing the work, or to email overnight.
Third: is there code on the other end that will do something without me? Only then is the answer a webhook, and the next section is about what you owe that choice.
There is a fourth question worth adding once your list grows past a handful: does this rule fire more than about once a day? If it does, it cannot be on your urgent channel regardless of how important each firing feels. High frequency and interruption are incompatible, and the fix is to tighten the condition or combine conditions rather than to accept the volume. The example on the ledger is a custom alert ANDing four separate oversold conditions into one notification instead of four separate rules, which is the cheapest volume reduction available.
The webhook is a different kind of decision
Sending an alert to a webhook that only logs it, or that forwards it into a tool you read later, is uncontroversial and useful. Sending an alert to a webhook that places an order is a different act. At that moment you have built unattended automation, whether or not you call it that, and it needs the things unattended automation needs.
Three of them are not optional. A size limit enforced by the code rather than by your intention, so that a rule firing five times in an hour cannot compound into five positions unless you decided it could. A daily stop, meaning a count or a loss level at which the endpoint stops acting and starts only notifying. And a check on the age of the message, so that a webhook delivered after a delay, or replayed, does not open a position against a level that stopped existing twenty minutes ago.
The failure mode you should design for first is not a wrong trade, it is silence. A webhook endpoint that is down accepts nothing and tells nobody, and from the alerts side everything looks normal because the message was dispatched. So give every order placing webhook a second destination on a chat channel with a short summary of what it did, and check that the two agree. If your endpoint reports nothing for a week while the rule's last fired date on the ledger has moved, you have found a break you would otherwise have discovered by noticing a strategy quietly stopped working.
Test the path before you trust it. The test fire control on each row exists for this: fire the rule deliberately, confirm the message arrives at the endpoint in the shape your code expects, and confirm your code does the harmless version of the right thing. Do this when you create the rule and again after any change to either end.
The rules that should not have a channel at all
Some conditions are worth tracking and not worth being told about. Anything you would review on a schedule rather than react to belongs in that category: a condition that informs position sizing next month, a slow moving screen, a background regime measure.
The ledger has a History tab beside the main list, and the row level toggle lets you pause a rule without deleting it. Between them you can keep a rule alive and unobtrusive, then read its firings when you sit down to review, which is the correct treatment for anything that never changes what you do today. The header tile counts active rules against paused ones, so a paused rule stays visible in your estate rather than disappearing.
Reviewing the routing when your estate grows
Channel assignments rot in one direction. Rules migrate toward the urgent channel over time because each individual promotion feels justified, and nothing ever migrates back. Once a quarter, go down the ledger, look at each row's channel badge, and ask the first of the three questions again. Demote everything that fails it.
While you are there, use the last fired dates as a liveness check. A rule on your urgent channel that has not fired in months is either watching something that stopped happening or it is broken, and the row cannot tell you which. Test fire it and at least eliminate the delivery path as the cause.
One last boundary, because the webhook option makes it easy to blur. A channel choice changes who or what finds out, and it changes nothing about your exposure. No routing decision on this page stops a position, and the controls that do stop things live on the execution side: the risk guards on an Autopilot profile, and the pause and emergency kill switch actions there, which are manual buttons somebody has to press. If your safety plan for an automated rule is that a notification will reach you in time, you do not have a safety plan, you have a notification.