Skip to content

Channels

A watch lists the channels it wants. Each is delivered independently, and a failure on one does not stop the others.

Type Status Configured by
telegram Supported telegram_bot_token + telegram_chat_id
push Supported (Android) FIREBASE_SERVICE_ACCOUNT_JSON + a signed-in device
email Not implemented as an alert channel
channels: [telegram] # the default chat
channels: [{ type: telegram, chatId: "-1001234567890" }] # a specific chat
channels: [telegram, push] # both

A bare string uses the configured default destination for that channel. The object form overrides the destination for that watch only, which is how you route different watches to different Telegram chats from one bot.

Watcher does not fail — it substitutes a console notifier and warns at startup. Alerts are printed instead of sent, which is what you want in development and worth knowing about in production:

Telegram is not configured — falling back to console for the telegram channel.
  • Some channels worked → the run counts as notified, and the failures are recorded on the run.
  • Every channel failed → the run is notify-failed, and the alert is stored and replayed on the next run, up to five attempts. See Failures and retries.

Alerts render per channel, but always carry the same content: a header, the one-line summary, the evidence quote with its date when present, and the evidence link.

The weak tier is visually distinct — “❓ Possible update (unconfirmed)” rather than “🔔” — so an unconfirmed alert can never be mistaken for a confirmed one at a glance.

Operational problems (a watch whose sources all failed, a crashed run) are sent as ⚠️ health alerts, separately from event alerts, to TELEGRAM_ADMIN_CHAT_ID when set and otherwise to the normal chat. They are deliberately formatted differently so you can filter them. See Monitoring.