Why a Telegram bot for trade notifications loses events
A notification channel seems simple while the market is calm. During a volatility spike, dozens of fills per second occur on a single instrument, and gaps, duplicates, and delays of minutes appear in the stream. The trader learns about the position from trade history and stops trusting the alerts.
Missed notifications are born at the junction with the exchange feed. If the event stream breaks and reconnection resumes from the current moment without backfilling the missed window, fills during the outage disappear without a trace: the bot has neither a record nor a message.
Event duplicates are the flip side of the same fault tolerance. Redelivery after a timeout without an idempotency key turns one trade into two or three messages, and a trader accustomed to noise stops responding to alerts.
The third class of failures is message sending limits.
Telegram limits both the frequency per chat and the bot's total stream: when the limit is hit, the message is not buffered but dropped, so a naive retry with a fixed pause only accelerates the queue and increases signal delay.
We'll break down how this is solved: an event log with delivery confirmation, idempotent trade keys, priority queues, and monitoring the time from execution on the exchange to the message in chat.
Exchange event coverage and reaction speed
The flow of exchange events is wider than what is visible in the interface: order placement, partial fill, full close, cancellation with reason, stop order trigger, margin change, position liquidation.
If events are not categorized by type, the on-call person drowns in messages and stops reading the channel — and the real signal is lost along with them.
Partial fill is the main source of noise and at the same time the main risk.
An order for ten lots is assembled from several trades at different prices, and a notification for each turns the channel into a feed; waiting for a full close is dangerous — when half the volume is filled, the position remains open unnoticed.
A working scheme: the first partial fill goes out immediately, the rest are aggregated by order within a short window, and the order status is recalculated based on the remaining amount.
Cancellation is a separate class, and the reason in it is more important than the fact. Time to live expired, exchange risk control removed it, trader canceled manually, it failed self-trade prevention — the on-call person's reactions differ.
Therefore, in the cancellation notification we include the code and text of the reason, the remaining volume, and a link to the original order.
Reaction speed is determined by the method of data retrieval. The stream of user events over a persistent connection to the exchange (Binance) delivers an event in fractions of a second; periodic polling of logs lags by seconds and hits request rate limits. The main channel is the persistent connection; polling remains a fallback for connection loss.
Account compatibility is solved by reducing to a single event schema: spot, margin, and futures accounts return a different set of fields, but in the bot they are converted into a unified format — with common filters, thresholds, and delivery routes to a personal chat or team channel.
Notification delivery methods: comparison of options
The exchange provides data in two fundamentally different ways: it pushes events over a persistent connection or responds to requests in a request-response pattern.
This choice determines notification delay, bot behavior during a connection loss, rate limit consumption per key, and how the system handles growth in the number of tracked pairs.
Below are the options that are actually chosen between when building a notification channel. Each has its own class of constraints: polling frequency, a cap on simultaneous subscriptions, requirements for a public address, and source verification.
| Option | When it fits | Limitations |
|---|---|---|
| Subscription to events over a persistent connection | Need reaction to the fact of a trade, many instruments, latency is critical | The connection must be maintained and restored together with subscriptions; the venue has a cap on the number of streams |
| Periodic polling via request-response | Few instruments, a delay of one interval is acceptable | Delay equals the polling step, limits are counted per key, load grows linearly with the number of pairs |
| Callback from the exchange to our address | The venue itself reports the event, minimal outgoing requests are needed | Not available at all exchanges; a public secure address and signature verification are required, retries on failure are redelivered |
| Third-party quote aggregator | Multiple exchanges in one interface, a unified field schema is needed | Delay and availability depend on the intermediary, some fields are lost, history recovery is limited |
In practice, channels are combined: a persistent connection covers fast events, and periodic polling once a minute reconciles the state and pulls in what was lost during a disconnection.
Such a hybrid removes the class of errors where "the notification arrived but the position is already closed," which is most costly during a sharp market move.
Bot development stages: from audit to handover
The stages are arranged so that by the time real trading is connected, no alert depends on an untested area. Each step ends with an artifact — a schema, configuration, or verification report — that can be opened and challenged.
- Integration audit. We analyze what data is available: exchanges in scope, required event types (trade execution and partial fill, order cancellation, margin change), request rate limits, permissions of issued keys. The result is a source map and a list of constraints that must be taken into account in the design.
- Flow design. We fix the event path: source → normalization to a unified format → filtering rules → routing by recipients → delivery to chat. We separately specify deduplication, message ordering, and behavior during channel loss.
- Setting up rules and thresholds. We assemble user scenarios: by volume, by instrument, by operation type, with grouping of noisy events. A rule can be enabled, muted, or converted to a digest without code changes.
- Test environment. Exchange sandbox plus a synthetic event generator: we run rare cases — partial fill, cancellation, time discrepancy — on which bots usually fail in real trading.
- Load testing. We provide an event stream above the estimated volume and see whether delivery delay grows, whether notifications are lost, and whether the connection recovers after a disconnection.
- Solution handover. We provide source code, flow diagrams, configurations, instructions for adding rules, and descriptions of emergency situations. After that, your team can expand the alert set.
What is included in the delivery: configurations and regulations
The delivery includes not only a working bot but also materials that the client's team continues to work with on its own: settings, regulations, documentation, and segregated access. Below is what exactly remains with you after handover and how to use it without our involvement.
- Bot configuration. A settings file with trigger thresholds for each pair, a list of tracked instruments, message templates, and a quiet-hours schedule — thresholds are changed without code edits.
- Event processing schema. The path from the quote source to the chat message with failure points, delivery retries, and behavior during a connection loss — you can see where the signal may be delayed.
- Response regulations. Who receives a notification, in what order, what is considered critical, and when escalation to the on-call person is required — with target response time specified.
- Access rights. Roles in the control panel: one area can change thresholds, another can only view history; service keys are issued separately and are subject to rotation.
- Documentation. Administrator instructions, a post-failure startup checklist, the procedure for updating settings and adding new trading pairs.
- Logs and metrics. History of delivered signals, share of successful sends, and delay from event to message — they show whether the system is operating normally.
- Handover materials. Source code, deployment manifests, and settings backups — if desired, the system can be redeployed on your infrastructure.
Describe the task — we'll come back with an estimate and plan, and we'll fix the delivery scope before work starts.
Case study: restoring the signal flow after a failure
Where it broke
The bot sent traders notifications about trade executions and stop order triggers in Telegram.
In a calm market everything worked, but during a volatility spike hundreds of events per second arrived at the handler: some messages were dropped due to sending limits, some were duplicated, and the trader saw a trade minutes after the fact.
According to logs before the rebuild, the share of missed events reached 18%, and incident investigation took hours — no one could quickly determine whether the signal was lost or never existed.
What was rebuilt
Events were moved to a priority queue: trade execution and stop trigger are processed before informational summaries.
Identical events for the same instrument are merged into a single message with an update instead of a continuous stream, and sending uses an increasing pause on retry and delivery confirmation — a message is not considered delivered until the channel confirms receipt.
An end-to-end event counter made it possible to notice a stream break and backfill what was missed, and the delay from event occurrence to delivery became the main metric: a deviation above the threshold sends an alert to the engineer.
A month after the rebuild, the miss rate was 0.4% instead of 18%, delivery delay was 2–3 seconds instead of minutes, and response to channel failure was 4 minutes instead of two hours of manual investigation.
The stream withstood several days of elevated volatility without losses: channel reliability is now measured by a metric, not by trader complaints.
How event subscription differs from account polling
Event subscription and account state polling are two delivery models. With a subscription, the bot holds a persistent connection, and the exchange itself sends a message at the moment the balance, position, or order status changes.
With polling, the bot requests an account snapshot on a schedule and calculates changes by comparing it with the previous one.
| Schema | How data arrives | When it fits | Limitations |
|---|---|---|---|
| Event subscription | Message at the moment of change | Alerts on trades, stops, partial fills | Requires channel liveness monitoring and backfilling missed windows |
| Account state polling | Snapshot on a schedule | Balance reconciliation, reporting, rare changes | Changes between requests are not visible, there is a request rate limit |
| Hybrid | Subscription plus periodic reconciliation | Trading alerts where data completeness matters | More complex to support: two schemas and reconciliation rules |
The limitations of each mode manifest differently. The weak point of subscription is a connection break: while the channel is being restored, events are lost unless a backfill window is stored.
The weak point of polling is the schedule step: a trade opened and closed within one interval will not appear in a notification at all.
Therefore, the choice of schema for trading alerts is almost always hybrid: subscription provides completeness of data on execution facts, and snapshot reconciliation confirms the final account state after disconnections.
We fix event order, discard duplicates, and keep a delivery log — in case of discrepancy, it is clear at which step the notification was lost.
The acceptance metric is the share of events that reached the recipient and the delay from trade execution to the message in Telegram. We verify both values on a test account before putting the bot into real trading.
Technical concerns: limits, delays, reliability
Platform limits and delivery delays are the two places where trading notifications break most often. Telegram limits the sending rate to a single chat, so a stream of trades cannot be broadcast line by line: during an activity spike, messages queue up and some are lost. Below are three scenarios that we address at the processing level, not "by eye."
We test failures separately: unavailability of the exchange stream, loss of connection to the platform, service restart. Events go through a queue with delivery confirmation, so after recovery, processing continues from the last confirmed position, not from the beginning.
What happens if there are more trades than the platform allows through?
The stream is aggregated: trades close in time for the same instrument are combined into a single notification with a summary. The threshold is set by the user — by volume, by price, or by a specific instrument.
During a peak, the queue is processed by priority: critical triggers go first, informational ones follow.
How far behind the real trade is the notification?
We measure two segments separately — event processing on our side and delivery through the platform. The first is controllable and fits within fractions of a second; the second depends on the recipient's network.
Therefore, the notification shows the event time, not the sending time: the delay is visible, and you don't have to guess.
A message was not delivered — will it be lost?
No. The notification receives an identifier, and sending is considered complete only after confirmation. On error, a retry is performed with an increasing interval; during prolonged unavailability, it accumulates in a buffer.
An undelivered event remains in the log and is included in the report, so a discrepancy between the exchange and notifications is investigated rather than left unnoticed.
Let's discuss the task and come back with an estimate and plan
Discussion of the task begins with input data: without it, the estimate of the scope of work turns into a range, and the work plan turns into a list of assumptions.
Below is what to send so that we come back with a concrete estimate and plan, rather than clarifying questions a week later.
- Exchanges and markets. Where notifications are needed — spot, derivatives market, specific pairs, or entire listing sections. This determines the stream volume and the data subscription method.
- Trigger events. Price reached a level, volume increased, price changed by a specified percentage over an interval, an order was executed, transfer status changed. We describe each formally to avoid duplicates and false triggers.
- Recipients and channels. Personal chat, shared group, a separate section for a specific strategy. Who receives notifications and whether there are those who need a reduced set.
- Message format. What should be in the text: pair, direction, trigger value, event time, link to the chart. We immediately decide whether buttons are needed — disable notification, snooze, view details.
- Quiet rules. Night windows, message limit per minute, combining similar events into one. This is what most often breaks trust in the bot after launch.
- Access. Read-only keys, exchange test environment, a separate test channel where the bot writes before being moved to production.
- Operating mode. How many people receive notifications, expected number of events per day, whether a log of delivered messages and analysis of missed ones is needed.
After that, we fix the scope of work, the order of stages, and the point at which you accept the result on the test environment. Describe the task — we'll come back with an estimate and plan.