Watchman Monitoring Webhooks Update: New Events, Payloads & UI

Hey folks! We’re happy to announce that we’ve just released a huge update to the Webhooks feature in Watchman Monitoring. Here’s what’s changed:

Setting up an endpoint

New “All events” firehose option. When you create an endpoint, it now defaults to receiving all events instead of making you hand-pick each one.
Two-mode event selector. You choose between All events or Specific events, with validation so you can’t save a broken configuration, plus warning callouts (for Beacon-related events) when relevant.
Refreshed event descriptions and a new transition reference explaining how status changes map to events, so it’s clearer what each event actually means.

Webhook payloads now include richer, more meaningful fields: severity, previous_severity, mute_type, is_muted, and is_hidden.
Backward compatible — the old integer fields (status_code, previous_status, new_status) are still sent alongside the new ones, so existing integrations keep working without changes.
Slack-formatted messages show both the legacy and the new fields.

Smarter alert/warning triggers. The “Plugin alert” event (now labeled “Plugin alert / warning”) fires on more of the transitions users actually expect: entering Warning from OK or Informational, and entering Alert from OK, Informational, or Warning — so escalating from a warning to a full alert now sends an alert webhook, which it previously didn’t. It still won’t fire on de-escalations or a plugin’s first report. The underlying plugin_alert event type is unchanged, so existing integrations keep working.
No more duplicate deliveries. Previously an event could match multiple subscriptions and fire more than once; now each endpoint resolves to a single prioritized event per trigger.
Suppression-aware routing. The firehose (“all events”) subscription receives everything including suppressed events, while normal specific-event subscriptions respect suppression rules.

“Send test” now behaves like a real delivery. Test sends are recorded as actual delivery rows (flagged test: true) and go through the same worker/pipeline — so what you see in a test genuinely reflects production behavior. Test failures don’t count against your endpoint’s failure counters.
Deliveries page gets Real / Test tabs, badges marking test rows, and a manual refresh button for pending deliveries so you can check status without a full page reload.