The most useful decision I made about bot alerts was deciding which bots don't get to alert me.
Why Telegram
For a one-person setup, a Telegram bot is the cheapest good alerting channel: a bot token, a chat id, an HTTP POST. It reaches my phone instantly, it's free, and it doesn't need an app I have to build or an inbox I have to babysit. For anything that makes a decision I'd want to know about in real time, that's plenty.
# The whole integration is basically this
requests.post(
f"https://api.telegram.org/bot{TOKEN}/sendMessage",
json={"chat_id": CHAT_ID, "text": msg},
)(Token and chat id come from the environment, never the repo — masked in every screenshot.)
The part people skip: not everything should alert
I run paper-trading and test bots that never touch real money. Those deliberately have no Telegram configured. That means a send attempt fails — and that failure is expected behavior, not an incident. It took me one round of alert fatigue to internalize this: if every bot pings me, I stop reading the pings, and then I miss the one that mattered.
So the rule is simple and it's about the receiver, not the sender:
- Bot makes a real decision I'd act on → Telegram wired up, real sends.
- Bot is a paper/backtest/experiment → Telegram intentionally off. A failed send is normal. Its output lives on its dashboard, which I pull when I choose to, not when it chooses to interrupt me.
Placeholder — real capture pending, token/chat id redacted.
The honest part
Alerting is a signal-to-noise problem, and the default failure mode is too much coverage, not too little. Wiring Telegram into everything feels responsible and is actually how you train yourself to ignore it. The discipline is to reserve the interrupt channel for the small set of events you'd genuinely act on, and let everything else sit quietly on a dashboard you pull from.
If a "failed to send alert" line in a log ever makes you nervous, first ask whether that bot was ever supposed to alert at all. For half of mine, silence is the correct output.