Trading Bot Monitoring: How to Catch Failures Before They Get Expensive

A trading bot that's running doesn't draw attention. Unfortunately, neither does one that has quietly stopped - and that's the real problem. Whether it's a dropped connection, a frozen platform or a computer restart: trading bot monitoring has to assume that precisely the component meant to raise the alarm is the one that fails.

Why a bot can't report its own failure

The obvious solution - the bot sends a message when something goes wrong - only covers errors the bot itself still notices. If it crashes, the platform freezes or the machine goes down, no message arrives. The fix inverts the logic: the bot reports at fixed intervals that it's still alive, and an independent party raises the alarm when that report stops coming. This principle, often called a heartbeat or dead man's switch, also catches the failures where nothing can be reported anymore.

What should trigger an alert - and what shouldn't

• Immediately: a missing heartbeat, a position that doesn't match what the bot believes it holds, a daily loss limit reached, rejected orders
• Promptly: stale price data, an unusual number of orders in a short time, a connection that keeps dropping
• Log only: individual signals, normal entries and exits, routine messages - get notified about everything and you'll miss the one message that counts

The most dangerous state: bot and account disagree

After a restart or a dropped connection, the bot knows its state only from its own memory - or not at all. If it thinks it's flat while a position is still open at the broker, nobody is managing that position. If it thinks it's in a trade that has long since closed, it may send exit orders that open a new position in the opposite direction. A robust bot therefore reconciles its own state with the actual account at startup and at regular intervals - and stops on a mismatch instead of trading on.

A kill switch that doesn't depend on the bot

A kill switch ends trading: cancel open orders, block new ones and, depending on how it's defined, close positions. It has to work even when the bot itself is the faulty component - a button inside a frozen bot helps nobody. And it should survive a restart: a triggered kill switch that's forgotten after rebooting isn't one. Releasing it afterwards is a deliberate manual step.

What should be protected independently of the bot

• Protective stops placed as orders at the broker where possible, rather than only monitored inside the bot, so they survive a failure - whether and how that works depends on the broker and the connection
• A daily loss limit at account level, if the broker offers one, as a second line behind the bot's own logic
• A log stored outside the bot, so a failure can be reconstructed afterwards

For the role the server and connection play in resilience, see the article on a VPS for an ATAS trading bot.

For how notifications via Telegram or webhook are set up, see the article on ATAS webhooks.

Good monitoring does nothing visible day to day - it only shows on the one day something goes wrong. That day is exactly why it pays to have it set up beforehand, rather than finding out afterwards how long the bot had been standing still.