Bot type
One alert when it crosses, not forty while it wobbles
A Telegram price alert bot watches thresholds a user sets and messages them when one is crossed, with hysteresis so an oscillating price does not fire repeatedly. End-to-end latency is seconds, not milliseconds. It is not suitable for anything where that difference decides the trade.
Price alert bots: price, timeline and limits
- Fixed price
- $5,000 USD
- Delivery
- 21 calendar days from kickoff
- End-to-end latency
- Seconds from price move to delivered message
- Feed ceiling
- Price APIs commonly rate-limit to a few requests/second per key
- Broadcast ceiling
- ~30 messages/second bot-wide
- Blocked recipients
- Send fails explicitly and the subscriber is dropped
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Price alerting is the simplest build in the crypto half of this catalogue and the one most often done badly, in a way that is invisible until it is deployed. The naive implementation compares the current price to a threshold and fires when it crosses. On a real market that price does not cross once — it oscillates around the level for several minutes, and the user receives thirty messages in four minutes and mutes the bot permanently.
The fix is hysteresis: once fired, an alert does not re-arm until the price has moved a defined distance back through the threshold. It is a small amount of code and it is the difference between a tool people keep and one they disable on the first volatile day. The same applies to alert expiry, cooldowns, and a per-user ceiling on how many alerts can fire in an hour.
The second thing worth being straight about is latency. Polling a price feed, evaluating thresholds, and sending through Telegram adds up to seconds. For a user who wants to know that ether crossed a level, that is entirely adequate. For anyone whose strategy depends on sub-second reaction, a Telegram bot is the wrong tool and no amount of engineering changes that — the platform's own send pacing sets a floor.
How the build runs
The user sets a threshold in one message
Asset, direction, level, and whether it repeats. Anything longer than one message for something this simple loses the user, and this is a build where the interface is most of the product.
commandsPrices are polled centrally, not per user
One poll per asset serves every alert on it. Polling per alert scales with users rather than with assets and will exhaust a data provider's rate limit almost immediately.
webhookThresholds are evaluated with hysteresis
An alert fires on crossing and then disarms until the price has retreated by a set distance. This single rule is the difference between a tool people keep and one they mute.
webhookDelivery is capped per user per hour
A volatile day should not produce a hundred messages. Beyond the ceiling, alerts are aggregated into one summary rather than dropped, so nothing is lost and nobody is flooded.
broadcastOne-shot alerts disarm themselves
Most alerts are answers to a single question. Defaulting to fire-once, with repeating as an explicit choice, matches what people actually want and keeps their alert list short.
inline-keyboardFeed failures are visible rather than silent
If the price source stops responding, users are told alerts are paused. A monitoring tool that fails quietly is worse than none, because the user believes they are covered.
broadcast
What Telegram will and will not let you do
End-to-end latency from price move to delivered message is measured in seconds.
Poll interval, evaluation and Telegram send pacing each contribute. This is stated to users as a figure rather than described as real time, because the difference matters to anyone trading on it.
A bot may send roughly 30 messages per second overall.
A sharp move that trips ten thousand alerts takes minutes to deliver fully. Alerts are prioritised by proximity to the threshold so the most urgent go first, and the tail is honest rather than hidden.
Price feed APIs rate-limit per key, commonly to a few requests per second.
Polling is centralised per asset and cached. The binding constraint is nearly always the data provider, not Telegram, and the architecture is shaped by that rather than the reverse.
A bot cannot message a user who has blocked it, and the send fails explicitly.
Blocked users have their alerts suspended rather than retried indefinitely, which otherwise consumes send budget that active users need.
Telegram gives no read receipt, only a send confirmation.
You can show that an alert was delivered, never that it was seen. Copy describes delivery and does not imply the user acted on it.
When not to build this
- Your users trade on sub-second reaction. Telegram's send pacing alone puts a floor under latency that no implementation removes.
- You need alerting on hundreds of exotic pairs. Data provider coverage and cost become the whole project, and the bot is the easy part.
- You already run a trading platform with alerting built in. A second alert source with different thresholds produces contradictory notifications.
- You want it as a standalone paid product with no other reason for users to be in your bot. Price alerts are widely available free, and this works best attached to something else.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework and the alert management interface. |
| Cloudflare Workers | current | Runtime, with cron-driven polling and evaluation. |
| Cloudflare D1 | current | Alerts, armed state, cooldowns and delivery history. |
| Cloudflare KV | current | Latest price cache shared across evaluation invocations. |
| TypeScript | 5.9 | Strict mode, with prices as integer minor units rather than floats. |
Questions people ask before committing
Why does hysteresis matter so much?
Because a price does not cross a level once. It oscillates around it, and a naive comparison fires on every crossing — thirty messages in four minutes, then a mute. Hysteresis is a few lines of code and it is the entire difference between a retained user and a lost one.
How fast is the alert, really?
Seconds, from poll interval plus evaluation plus Telegram send pacing. We publish the figure rather than describing it as real time, because a user trading on the difference deserves to know it before they rely on it.
What happens on a day when everything moves at once?
Alerts are prioritised by how close they are to their threshold, and each user has an hourly ceiling above which alerts aggregate into a summary rather than being dropped. Nothing is lost and nobody receives two hundred messages.
Which price sources can it use?
Any provider with a rate limit that fits the polling model. The choice is usually decided by coverage of the specific pairs you need and by cost, both of which dominate the engineering here.
Do alerts stop if the price feed goes down?
They pause, and users are told. A monitoring tool that fails silently is worse than none at all, because the user goes on believing they are covered when they are not.
Why is this cheaper than the other crypto builds?
Because it holds no value, moves no funds and has no regulatory surface. Almost all of the cost in the wallet and launch builds is failure handling around money, and none of that applies here.