Alerts
Where problems reach you: email on every plan, plus Slack, Discord, Teams, PagerDuty, Opsgenie, incident.io, Datadog, New Relic, Prometheus, Telegram and your own signed webhook.
An alert channel is one place WebhookVault sends you bad news. A watchdog going quiet, a forward giving up, a payment failing: each one goes to every channel subscribed to it.
Email is the floor. It works on every plan, it cannot be switched off, and it needs no setup beyond confirming who should receive it. Everything else is an integration you add on top.
What raises an alert
| Event | Raised when |
|---|---|
watchdog.alarmed | A watchdog passed its expected interval plus grace with no matching capture |
watchdog.recovered | A matching capture arrived while that watchdog was alarmed |
delivery.dead_letter | Deliveries to an action exhausted their retries and parked. One alert per action per outage, with a count |
billing.past_due | The subscription entered the dunning window |
billing.payment_failed | A renewal charge was declined |
Each channel subscribes to the ones it wants, with an optional severity floor so a noisy channel can take only what matters.
Parked deliveries are one alert per outage
When an action's destination goes down, every delivery to it eventually parks. You get one alert for that action, not one per request: "Deliveries to Orders API are parking: 1 so far". Further deliveries that park are counted onto that alert in your alert history without being sent again, and the alert links to that action's parked deliveries on the endpoint.
The count stops when a delivery to the action succeeds. That sends one recovered notice
(delivery.recovered, which travels on the delivery.dead_letter subscription), and PagerDuty,
Opsgenie and incident.io resolve the incident the first alert opened. If no delivery parks for
30 minutes, the next one that does sends a fresh alert; until a delivery succeeds it stays on
the same incident, so PagerDuty does not open a second one.
Where alerts can go
Email: your workspace's confirmed technical contacts, or the owners when there are none. Managed from Contacts, not here. Always on.
Chat: Slack, Discord and Microsoft Teams. Slack and Discord can be connected in one click: you pick the channel in Slack's or Discord's own interface and nothing is copied by hand.
On-call: PagerDuty, Opsgenie and incident.io. On these an alarm and its recovery are the same incident: the recovery resolves what the alarm opened, so nobody is paged twice for one outage or left closing incidents by hand.
Telemetry: Datadog, New Relic and Prometheus, so an alert sits beside whatever else your team already watches.
Telegram: a bot you own, messaging a chat or group you pick.
Your own receiver: a signed webhook. The body is JSON, and when you set a signing secret we
send a timestamped signature so your receiver can prove the alert came from us and reject a
replay. In the payload, subject_id is the id of what the alert is about: for a parked-delivery
alert and its recovered notice that is the action's id (it used to be the request's id), so your
receiver can pair the two.
Each one asks for something different: a URL, a key, a region, a chat. The app tells you exactly what and where to find it as you add it.
Nothing counts until it is tested
A newly added channel is untested. Press Send a test and WebhookVault sends a real message and shows you what the provider said, verbatim. Only a send that the provider accepted marks a channel working.
Change the credential or the destination and the channel goes back to untested, because the route it proved is no longer the route it will use.
A channel whose sends keep failing is marked failing, and its alerts also go out by email so nothing is lost while you fix it. The reason sits on the channel, in the provider's own words.
The history
Every send is recorded: which channel, which event, whether the provider accepted it, what came
back, and whether it was a test. That record is what answers did anyone actually get told.
It is on the Alerts page, filterable and exportable, as well as through the API, where
GET /api/v1/alert-channels/deliveries takes eventKind=delivery.recovered to list just the
notices that closed a parked-delivery incident.
It is kept on the same clock as your audit trail.
Plans
Email alerts are on every plan, including Free. The integrations above start on Pro, with a per-workspace channel limit. A workspace that moves to a plan without integrations keeps its channels; they stop sending, and start again if the plan allows it later.
Through the API
GET /api/v1/alert-channels/kinds lists what your workspace can add and what each one needs.
curl https://app.webhookvault.net/api/v1/alert-channels \
-H "Authorization: Bearer $WV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"kind": "slack",
"name": "Ops Slack",
"secret": "https://hooks.slack.com/services/…",
"events": ["watchdog.alarmed", "watchdog.recovered", "delivery.dead_letter"]
}'Then prove it:
curl -X POST https://app.webhookvault.net/api/v1/alert-channels/{id}/test \
-H "Authorization: Bearer $WV_API_KEY"A failed test answers 200 with delivered: false and the provider's message in detail:
the send failed, not the request.
Credentials are write-only. No route returns one; a channel reports only whether a credential is set and when.
The full reference is under Alert channels in the API reference.
Watchdogs
A dead-man's switch per webhook stream: expect a matching capture at least every N with G of grace, and alarm through your alert channels when the window passes in silence.
Recycle bin
Deleting a captured request moves it to the workspace recycle bin, restorable for up to 7 days or until the plan's retention window ends. Only the retention sweep or a purge applied by WebhookVault support removes it for good.