---
title: "Alerts | WebhookRelay"
meta:
  "og:description": "Get notified when webhook delivery fails. Define alert policies, choose destinations (Email, Slack, Discord, Teams, Telegram, Pushover, SMTP or webhook), and Webhook Relay opens and resolves incidents automatically."
  "og:title": Alerts
  description: "Get notified when webhook delivery fails. Define alert policies, choose destinations (Email, Slack, Discord, Teams, Telegram, Pushover, SMTP or webhook), and Webhook Relay opens and resolves incidents automatically."
---

![Stripes](https://webhookrelay.com/docs/webhooks/alerts/images/stripes.svg)

Documentation

**Fundamentals**

# **Alerts**

Get notified when webhook delivery fails. Define alert policies, choose destinations (Email, Slack, Discord, Teams, Telegram, Pushover, SMTP or webhook), and Webhook Relay opens and resolves incidents automatically.

## [Get notified when webhook delivery fails](#get-notified-when-webhook-delivery-fails)

**Alerts** watch your buckets for delivery problems. You define a policy (what counts as a failure and when to open an incident), pick where notifications go, and select which buckets to monitor. When delivery outcomes cross the policy, Webhook Relay **opens an incident** and sends a notification. When delivery recovers, the incident **resolves automatically**.

For a short product overview, see the [Alerts feature page](https://webhookrelay.com/docs/webhooks/alerts/features/alerts/). For custom logic (e.g. alert only when a payload field is wrong), use [alerting from functions](https://webhookrelay.com/docs/webhooks/alerts/docs/webhooks/functions/alerting/) instead.

## [Create an alert](#create-an-alert)

1. Open **Alerts** in the Webhook Relay dashboard ([my.webhookrelay.com](https://my.webhookrelay.com)).
2. Click **New alert policy** (or **Create alert**).
3. Configure the three parts of the form:
  - **Destination** — where incidents should go
  - **Alert policy** — what to monitor and when to open
  - **Buckets** — which buckets this policy watches
4. Click **Create alert**.

![Create alert dialog — destination, alert policy for delivery failures, and bucket selection](https://webhookrelay.com/docs/webhooks/alerts/images/docs/webhooks/alerts/create-alert.png)

## [Destination — where should incidents go?](#destination-where-should-incidents-go)

Pick a notification channel and enter its credentials. Fields are validated before saving.

![Alert destination types: Email, Slack, Discord, Telegram, Microsoft Teams, Pushover, SMTP email, Webhook](https://webhookrelay.com/docs/webhooks/alerts/images/docs/webhooks/alerts/destinations.png)

Supported destination types:

| Destination | Use it for |
| --- | --- |
| **Email** | Inbox notifications |
| **Slack** | Channel posts for eng / on-call |
| **Discord** | Server / channel webhooks |
| **Telegram** | Bot messages |
| **Microsoft Teams** | Channel notifications |
| **Pushover** | Mobile push for on-call |
| **SMTP email** | Your own mail server |
| **Webhook** | Any HTTPS endpoint (PagerDuty, Opsgenie, custom bots, …) |

Give the alert a name so you can tell policies apart in the list. You can create multiple alerts with different destinations for the same buckets if you want fan-out (e.g. Slack for the team and a webhook into your incident tool).

## [Alert policy — when should an incident open?](#alert-policy-when-should-an-incident-open)

![Alert policy: delivery failures, any failed delivery or error rate threshold, rolling window, and recovery behavior](https://webhookrelay.com/docs/webhooks/alerts/images/docs/webhooks/alerts/alert-policy.png)

### [Alert type](#alert-type)

Currently supported:

- **Delivery failures** — fire when deliveries to a watched bucket fail (errors, timeouts, unreachable destinations).

### [Description (optional)](#description-optional)

Free-text note included in **incident** and **recovery** notifications — e.g. `production stripe payments` — so on-call knows which system is affected.

### [Incident condition](#incident-condition)

Choose how sensitive the policy is:

| Condition | Behavior |
| --- | --- |
| **Any failed delivery** | Open on the first failure. |
| **Error rate threshold** | Wait for a representative sample before opening (reduces noise from one-off blips). |

### [Rolling window](#rolling-window)

The recovery window for the policy (e.g. **5 minutes**). With **Any failed delivery**:

- **One failure** opens the incident.
- The incident **resolves** after a complete rolling window with **no failures** and **at least one successful delivery**.
- **Each bucket is evaluated independently** — failures in two buckets open two incidents.

## [Buckets](#buckets)

Use the **Buckets** panel on the right to select which buckets this alert watches. Search and filter as needed, then toggle each bucket on.

Only selected buckets are evaluated. Leave a bucket off if you do not want delivery noise from it to open incidents.

## [Incidents](#incidents)

When a policy condition is met on a watched bucket, Webhook Relay opens an **incident**. Incidents are the live record of delivery problems — one per bucket per policy — and appear on the Alerts page with status, failure snapshot, and open/resolved times.

![Alerts page showing open incidents, incident chart over time, and a table of status, bucket, policy, failure snapshot, opened and resolved](https://webhookrelay.com/docs/webhooks/alerts/images/docs/webhooks/alerts/incidents.jpg)

### [When an incident starts](#when-an-incident-starts)

An incident **opens** as soon as the alert policy’s condition is met for that bucket, for example:

- **Any failed delivery** — first failed delivery
- **Error rate threshold** — after a representative sample exceeds the threshold

Each bucket is evaluated on its own, so two failing buckets under the same policy produce two incidents. Destinations on that alert receive an **incident opened** notification.

### [How an incident closes](#how-an-incident-closes)

An incident can end in either way:

1. **Automatically** — after a full rolling window with **no failures** and **at least one successful delivery**, the incident resolves and a recovery notification is sent.
2. **Manually** — resolve the incident from the Alerts UI (row actions) when you have fixed the issue and do not want to wait for the recovery window.

### [History and filtering](#history-and-filtering)

The Alerts page keeps incident history so you can always revisit what happened:

- **Chart** — open-incident volume over 7 / 30 / 90 days
- **Filters** — Policies, Open, Resolved, or All
- **Table** — Status, Bucket (and output), Policy (condition + window), Failure snapshot (counts and error rate), Opened, Resolved

Pair incidents with [webhook logs & monitoring](https://webhookrelay.com/docs/webhooks/alerts/features/webhook-logs/) to inspect the exact failing request, and with [durable retries](https://webhookrelay.com/docs/webhooks/alerts/docs/webhooks/durable-webhooks/) so failed deliveries keep retrying while you fix the destination.

## [Related](#related)

- [Alerts feature page](https://webhookrelay.com/docs/webhooks/alerts/features/alerts/)
- [Webhook logs & delivery monitoring](https://webhookrelay.com/docs/webhooks/alerts/features/webhook-logs/)
- [Durable webhooks](https://webhookrelay.com/docs/webhooks/alerts/docs/webhooks/durable-webhooks/)
- [Alerting from functions](https://webhookrelay.com/docs/webhooks/alerts/docs/webhooks/functions/alerting/) — custom request/response checks
- [Audit logs](https://webhookrelay.com/docs/webhooks/alerts/features/audit-logs/) — who created or changed alert policies

Did this page help you?