Pluralis Agora does not tell you when your node drops. It can fall out of the run, stop earning, and sit re-queuing for hours while you have no idea - unless you happen to SSH in and check. This is a small paste-and-run tool that pings you the moment your node's state changes, plus the one design lesson that makes node monitoring useful instead of noise.

The problem: silence, then noise

You live and die by whether your node is Active and earning. Nodes drop often, and every drop means hours of re-syncing earning almost nothing - with no notification from Pluralis. You find out by chance.

The obvious fix is a monitor that pings you, but here is the trap: naive monitors spam you into ignoring them. A monitor that checks "is the node OK?" every cycle and alerts on whatever it sees will fire the same warning over and over until you mute it. A monitor you ignore is worse than none. The fix is not more alerting - it is alerting only on real state changes, once each.

The core idea: alert on transitions, not states

The node logs its condition continuously. A naive monitor reacts to the current state every cycle. This tool tracks the last state it knew and alerts only when the state actually changes. Three transitions matter:

[GREEN] Caught a seat -> syncing

[DONE] Sync complete -> Active (earning)

[RED] Dropped -> re-queuing (act on this)

Each fires exactly once, at the boundary. Comparing against the last known state before sending is the entire difference between a useful monitor and alert fatigue.

The tool (paste-and-run)

Set the five values, run it on the same box as your node. No extra packages - just bash and curl, already on your box.

#!/bin/bash
# -- Agora State-Change Telegram Monitor --------------------------
TOKEN="PASTE_YOUR_TELEGRAM_BOT_TOKEN"   # from @BotFather
CHAT="PASTE_YOUR_TELEGRAM_CHAT_ID"      # your numeric chat id
BOX="Node 1"                            # any label for your alerts
LOG="/workspace/agora/logs/server_gpu0.log"  # your node's log path
POLL=30                                 # seconds between checks
# -----------------------------------------------------------------

STATE="queue"   # last known state

send() {
  curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d chat_id="$CHAT" -d text="$1" >/dev/null
}

while true; do
  LINES=$(tail -n 5 "$LOG" 2>/dev/null)

  # DROPPED (checked first - most urgent)
  if echo "$LINES" | grep -q "Maximum number of active nodes" \
     && [ "$STATE" != "queue" ]; then
    STATE="queue"; send "[RED] $BOX: DROPPED - re-queuing for a seat"

  # SYNC COMPLETE -> ACTIVE
  elif echo "$LINES" | grep -q "Sync complete" \
       && [ "$STATE" != "active" ]; then
    STATE="active"; send "[DONE] $BOX: SYNC COMPLETE - Active and earning"

  # CAUGHT A SEAT -> SYNCING
  elif echo "$LINES" | grep -q "\[SYNC\]" \
       && [ "$STATE" != "sync" ] && [ "$STATE" != "active" ]; then
    STATE="sync"; send "[GREEN] $BOX: caught a seat - syncing (not earning yet)"
  fi

  sleep "$POLL"
done

Run it in the background so it survives your SSH closing:

chmod +x agora_monitor.sh
nohup ./agora_monitor.sh > monitor.log 2>&1 &

Test that alerts reach you before trusting it: send yourself a one-off message through the same Telegram sendMessage API call the script uses, passing your token, your chat ID, and the text "monitor test". If your phone receives it, your token and chat ID are correct and the monitor will be able to message you.

Why the logic works

The heart is the STATE variable and the [ "$STATE" != ... ] checks. Each cycle, the script reads the last log lines - but it does not alert on what it sees. It first checks whether the state differs from last time. Only a genuine change sends an alert and updates STATE.

So a node sitting Active for three days, printing healthy lines the whole time, generates exactly one "now Active" alert and then silence until something changes. Drop the STATE check and you alert every cycle - that is the spam. Drop-detection is checked first because it is the event you most need to act on, and you never want it masked by a stale line lower in the log.

What it does NOT do

This monitor runs on the same box as your node - simple and dependency-free, but with one real blind spot: if the whole box dies (host failure, instance stopped, billing lapse), the monitor dies with it and cannot warn you. It only reports events it observes from inside a living box.

So it reliably catches node-state transitions but not total-host-death. Cover that separately - provider auto-billing, an occasional dashboard glance, or an off-box watcher. Stating this plainly matters: a monitor that silently fails when the whole box is gone is exactly the false confidence worth warning against.

Adapting it (checklist)

• LOG - point at your node's actual log path (printed in its startup output).
• State strings - the grep patterns match Agora's current log wording. If a future run changes the wording, update the strings; the logic is unchanged.
• POLL - 30s is plenty. State changes are not sub-minute events.

That is the whole tool: five values, one loop, three alerts, no dependencies, no server, no data but your own. Paste it, set your credentials, run it on your box - and know, once and cleanly, the moment your node catches a seat, starts earning, or drops.