Every alert channel I have ever built goes through the same life cycle. Week one, every ping feels important and I check the phone immediately. Week three, there are forty unread messages and I have started swiping the whole channel away without reading it. By week five the channel is muted and I miss the one alert that actually mattered, which was the entire point of building the thing. The wiring into Telegram takes maybe twenty minutes. Designing the filters so you still respect the channel two months later is the real project, and almost nobody does it.
So let me walk through both halves. First the plumbing, because you do need it, then the part that keeps the plumbing from drowning you.
The plumbing: one bot, one relay, several sources
The basic setup is a Telegram bot plus a small relay that sits between your alert sources and that bot. Creating the bot is trivial. You message BotFather inside Telegram, run the newbot command, pick a name, and it hands you an API token. Then you create a private channel or group, add the bot as an admin, and grab the chat ID. From that point, sending a message is a single HTTPS POST to the Telegram Bot API with your token, the chat ID, and the text. Any tool that can fire a webhook can now talk to your phone.
The mistake beginners make is pointing every alert source directly at that bot endpoint. TradingView alerts go straight in, an exchange price alert goes straight in, a whale tracker goes straight in, an RSS-to-webhook news bridge goes straight in. It works on day one and it is unfixable by day thirty, because you have no single place to apply rules. Every source has its own idea of formatting and frequency and none of them know about each other.
Instead, route everything through one relay you control. This can be embarrassingly small. A workflow in n8n or a similar automation tool, a cloud function, or a fifty-line script on a five-dollar VPS that exposes one webhook URL. Every source posts JSON to the relay, the relay decides what gets forwarded to Telegram and how. The relay is where all the intelligence lives. Sources stay dumb, which is good, because most of them are dumb anyway.
Give each incoming alert three fields at minimum, even if you have to infer them in the relay: a source (price, whale, news), a key that identifies what the alert is about (the ticker or the wallet address), and a severity. Everything that follows depends on those three fields existing.
Severity tiers, or why most alerts should not ping your phone
Here is the rule of thumb I hold myself to: an alert that vibrates my phone must be something I would plausibly act on within the hour. Not something interesting. Something actionable on that clock. When I audit my own channels honestly, maybe one alert in twenty clears that bar.
So the relay sorts everything into three tiers, and each tier gets a different delivery mechanism:
- Act now. A price crossed a level where I have a standing plan, a wallet I track opened or closed a large position, a liquidation cascade is underway in something I hold. These go to a dedicated Telegram channel with notifications on, sent with normal priority so the phone buzzes. This channel should be nearly silent on an average day. If it fires more than a handful of times a day, the thresholds are wrong, not the market.
- Worth knowing today. Funding rates drifting, a watched wallet doing something moderately unusual, news mentioning a ticker on my list. These go to a second channel sent with Telegram's disable_notification flag, so they appear in the channel but the phone stays quiet. I read them when I choose to look.
- Digest material. Everything else gets written to a queue instead of being forwarded at all. Once or twice a day, on a schedule, the relay flushes the queue as a single formatted message. Twenty minor events as one message reads fine. Twenty separate pings is how channels die.
The two-channel split matters more than it looks. If urgent and non-urgent share a channel, you cannot configure your phone to treat them differently, and Telegram's per-chat notification settings become useless. Separate chats give you separate mute states for free.
Dedupe windows, the filter nobody builds until it is too late
The single biggest source of alert fatigue is the same event firing repeatedly. Price chops across your alert level fourteen times in an hour and you get fourteen pings that all say the same thing. A whale wallet gets flagged by two different sources within a minute. A news story gets syndicated across six outlets and your keyword bridge dutifully forwards all six.
The fix is a dedupe window in the relay. Before forwarding anything, build a fingerprint from source plus key plus a coarse description of the event, something like price, BTC, crossed-65k-down. Keep a small table of recent fingerprints with timestamps. If the same fingerprint showed up within the window, drop the new alert silently, or better, increment a counter you include in the next digest so you know the level was tested repeatedly, which is itself information.
Window length depends on the source. For price-level alerts I use something in the range of thirty to sixty minutes, because a level being crossed again twenty minutes later is rarely new information. For whale activity, shorter, maybe ten or fifteen minutes, since a wallet doing three distinct things in an hour is genuinely three events. For news, longer, several hours, keyed on the ticker plus a rough headline signature, because syndication delays are long. These numbers are starting points, not gospel. The point is that the window exists at all.
Price alerts deserve one extra guard: hysteresis. Do not re-arm an alert the moment price crosses back over the line. Require it to move some meaningful distance away, say half a percent or an ATR-based buffer, before the level can fire again. This one rule kills most chop-induced spam on its own.
Quiet hours and the weekly prune
Last piece. Decide, in the relay, what happens overnight. My split is simple: only the act-now tier is allowed to page me between midnight and seven, and even then only for positions I actually hold, not watchlist items. Everything else that arrives overnight gets held and released with the morning digest. Crypto trades around the clock, but unless you are running size with real overnight risk, you are not going to act at 3am, and pretending otherwise just trains you to ignore the channel. If you do hold leveraged positions overnight, carve out an exception for liquidation-adjacent alerts and nothing else.
Then there is maintenance, which is boring and non-optional. Once a week, scroll the act-now channel and ask one question about each alert: did I do anything because of this? If an alert type has fired ten times and you acted zero times, demote it a tier or kill it. Alert configs rot the same way watchlists rot. The prune takes five minutes and is the difference between a channel you trust and a channel you mute.
One honest caveat: building good alert conditions upstream is its own problem. A raw price cross is a weak signal, and most whale-tracking feeds have no notion of severity at all, so your relay ends up guessing. This is roughly the problem we ended up building around at Blockcircle, where alerts carry context like historical hit rates and position sizing before they ever reach a webhook. But whatever generates your signals, the delivery architecture is the same: one relay, three tiers, two channels plus a digest, dedupe with hysteresis, quiet hours, weekly prune. Set that up once and Telegram stays what it should be, a thin pipe that only speaks when you would actually want to listen.