# Alerts

Get an email or Telegram message when a gateway starts failing, per source or workspace wide.

Source: https://docs.webhooker.eu/account/alerts/

Alerts tell you that deliveries are failing before your customers do. Channels
are created on a source's **Alerts** tab and can be scoped to that one source or
to every source in the workspace.

## Channels

| Channel | Fields |
| --- | --- |
| Email | **Recipient email** |
| Telegram | **Bot token**, **Chat ID** |

**Scope** is either **This source** or **All sources**. Several channels can be
active at once — email to a shared inbox, Telegram to the on-call chat — and each
can be enabled or disabled without deleting it.

To set up Telegram, create a bot with [@BotFather](https://t.me/botfather), copy
the token, add the bot to the target chat, and use that chat's id.

## What triggers an alert

| Trigger | When |
| --- | --- |
| Delivery exhausted | Every retry in the schedule failed for one event. |
| Destination unhealthy | The last 5 attempts to that endpoint all failed. |
| Circuit opened | 5 consecutive retryable failures paused the endpoint. |

All three are deduplicated per destination and kind within a 15-minute window,
so a broken endpoint sends you one message, not one per queued event.

There is no alert for a single failed attempt. A `500` that the next retry fixes
is not worth waking anyone up for.

## What an alert does not do

Alerts are a notification, not a control. Nothing is dropped or disabled when one
fires: deliveries keep retrying on the schedule, and events keep being accepted.
The recovery path is the [dead-letter queue](/deliver/retries-and-replay/) once
the endpoint is healthy.