bot-monitor — Log watcher and Telegram alerts

What it does

bot-monitor is the observability backbone for the entire scalper fleet. Run it once and it tails every poly5m and poly15m log file, parses the structured BUY / RESOLVED / EXIT events, dedupes them across restarts, and pushes formatted messages to Telegram. None of the scalping bots emit anything to Telegram on their own, so this process is what makes the fleet visible.

The edge

Centralizing alerts is not a vanity feature. Putting Telegram inside each bot would mean eight processes each holding a HTTPS socket to Telegram, eight dedupe states to keep in sync, and any Telegram outage tying up a bot's main loop. With bot-monitor, the bots write structured lines to disk at zero cost and a single watcher handles dedupe, rate limits, retries, and the (rare) Telegram outage. The bots stay focused on trading.

How it works

The script knows about every bot in the suite via the BOTS registry. For each one it tracks:

• logFile: rolling log written by the bot
• statsFile: JSON the bot updates on every cycle
• resolvedFile: JSON the bot appends to on resolution
• lockFile: PID file so the monitor can tell if a bot is alive

Four modes, selected by CLI flag:

1. monitor (default): tail every log file simultaneously. New BUY / WIN / LOSS / EXIT lines get parsed, deduped against the prior tail position, and pushed to Telegram.
2. --report: one-shot summary of every bot's balance, PnL, win count, loss count, open positions. Sent to Telegram and stdout. Good from cron once a day.
3. --pnl: queries Polymarket's trade-history API for the wallet and reconciles every fill against the bot's self-reported PnL. Catches drift between optimistic logging and on-chain reality.
4. --pnl --watch: same as --pnl but loops every 5 minutes.

The --reset flag wipes the dedupe state and re-emits the next event from each log, useful when alerts have drifted out of sync with reality.

Sample output

[25/05/2026, 15:57:14] [Resolution] 15m-sniper: WIN btc-updown-15m-2026-05-25-1557 → $4.85 | Bal: $26.35
[25/05/2026, 15:58:02] [Resolution] 15m-v6: EXIT btc-updown-15m-2026-05-25-1545 → loss $-4.21
[25/05/2026, 15:58:02] TG sent ✓
[25/05/2026, 16:02:14] [Resolution] 15m-sniper: WIN btc-updown-15m-2026-05-25-1600 → $5.12 | Bal: $31.47

Design targets

• Zero data loss: the dedupe state file (data/monitor-state.json) is written atomically after every Telegram send
• One Telegram call per resolution event, with HTTP 429 handling
• Survives restarts mid-event: re-reading the log from offset 0 is safe, dedupe drops what was already sent
• Heartbeat every 60s in monitor mode so you can tell the monitor itself is alive

FAQ

Why are the bots themselves not sending Telegram?

Earlier versions did. The result was double-sends after restarts, missed sends during Telegram outages that blocked the bot's main loop, and inconsistent message format across bots. Splitting it out fixed all three.

Do I need this if I only run one bot?

Probably yes. Even with one bot, the --pnl reconciliation catches log/reality drift you would otherwise only notice once a week when you reconcile manually. And you don't have to re-implement Telegram glue in the bot itself.

What's included

• poly5m/bot-monitor.js
• poly5m/scripts/monitor-run.sh (auto-restart wrapper)
• README with Telegram bot setup, dedupe-state recovery, and a pm2 ecosystem.config.js example