RB5009 Netwatch Telegram transition alerts (sanitized)

netwatch-telegram-flow.md

RB5009 Netwatch Telegram flow

sequenceDiagram
    participant N as RB5009 Netwatch
    participant L as RouterOS log
    participant A as Telegram Bot API
    participant C as Owner private chat
    N->>N: Probe 8.8.8.8 every 10 minutes
    alt Up to Down
        N->>L: main-wan-down
        N->>A: HTTPS sendMessage DOWN
        A->>C: Down alert
    else Down to Up
        N->>L: main-wan-up
        N->>A: HTTPS sendMessage UP
        A->>C: Recovery alert
    else No state change
        N->>N: No transition message
    end
    opt Telegram request fails
        N->>L: Generic send failure warning
    end
    Note over N: test-script is empty

Loading

The probe follows the active route. Telegram delivery requires Internet reachability; a complete loss of all WAN paths may prevent the alert.

rb5009-netwatch-telegram.md

RB5009 Netwatch Telegram alerts

Current behavior

The existing enabled Netwatch entry for 8.8.8.8 uses a simple ICMP probe every 10 minutes. A transition to down logs main-wan-down and sends a Telegram message. A transition to up logs main-wan-up and sends a recovery message. test-script is empty, so routine probe tests send no messages.

The probe follows the router's active route to 8.8.8.8; the log label main-wan does not bind it to a specific WAN. Telegram delivery also needs a working Internet route. The scripts use HTTPS certificate validation and a 10-second idle timeout; send failures produce a generic warning without printing the token.

Sanitized RouterOS template

Confirm there is exactly one matching entry, then replace <BOT_TOKEN> and <CHAT_ID> locally. The completed commands contain a credential and must not be committed, published, or pasted into logs.

/tool netwatch print count-only where host=8.8.8.8
/tool netwatch set [find where host=8.8.8.8] up-script=":log info main-wan-up; :do { /tool fetch url=\"https://api.telegram.org/bot<BOT_TOKEN>/sendMessage\" http-method=post http-header-field=\"Content-Type:application/x-www-form-urlencoded\" http-data=\"chat_id=<CHAT_ID>&text=RB5009+Netwatch%3A+8.8.8.8+UP\" check-certificate=yes idle-timeout=10s output=none } on-error={ :log warning \"netwatch-telegram-recovery-send-failed\" }"
/tool netwatch set [find where host=8.8.8.8] down-script=":log info main-wan-down; :do { /tool fetch url=\"https://api.telegram.org/bot<BOT_TOKEN>/sendMessage\" http-method=post http-header-field=\"Content-Type:application/x-www-form-urlencoded\" http-data=\"chat_id=<CHAT_ID>&text=RB5009+Netwatch%3A+8.8.8.8+DOWN\" check-certificate=yes idle-timeout=10s output=none } on-error={ :log warning \"netwatch-telegram-send-failed\" }"

The token is stored in RouterOS configuration and may be included in its backups. Protect access to both; do not use /export show-sensitive for routine verification.

Verification

:local n [/tool netwatch find where host=8.8.8.8]
:put [/tool netwatch get $n status]
:put [/tool netwatch get $n interval]
:put [:len [/tool netwatch get $n test-script]]
:put [:typeof [:parse [/tool netwatch get $n up-script]]]
:put [:typeof [:parse [/tool netwatch get $n down-script]]]
/log print where message~"main-wan-|netwatch-telegram-"

The syntax check parses each script without running it. A router-originated Telegram API test returned HTTP 200, and both saved scripts were read back exactly. A real down/up transition was not induced during setup.

Rollback

Restore the two original log-only actions; leave the probe and empty test-script unchanged:

/tool netwatch set [find where host=8.8.8.8] up-script=":log info main-wan-up" down-script=":log info main-wan-down"