# Alert channels

> Where StatusTick sends alerts: email, Slack, Microsoft Teams, Discord, Telegram, PagerDuty and webhooks, and how delivery, retries and acknowledging work.

An alert channel is a destination for incident alerts. Admins add channels in the organization settings, send a test message, and choose which channels each incident setting uses.

## Channels

| Channel | What it does | Set up |
| --- | --- | --- |
| Slack | Send notifications to Slack channels via webhooks | Organization settings |
| Webhook | Send HTTP requests to custom webhook endpoints | Organization settings |
| Microsoft Teams | Send notifications to a Microsoft Teams channel via a Workflows webhook | Organization settings |
| Discord | Send notifications to a Discord channel via a webhook | Organization settings |
| Telegram | Send notifications to a Telegram chat or group | Organization settings |
| PagerDuty | Trigger and resolve PagerDuty incidents via the Events API v2 | Organization settings |
| Email | Send alerts to a list of verified email addresses | Organization settings |
| incident.io | Hand incidents to incident.io through an HTTP alert source | Organization settings |
| Grafana IRM | Hand incidents to Grafana IRM through a webhook integration | Organization settings |

To hand alerts to another tool, connect PagerDuty.

## What an alert contains

Alerts are sent when an incident opens and when it resolves. Each alert says which monitor failed, the target, the failing regions, the error and when it started, with links to the incident and to **acknowledge** it. Acknowledging from the link stops escalation.

Heartbeat (cron job) alerts also name the job's problem and link to the run. A degraded cron job problem comes as a warning instead: it goes once to the destinations in step 1 of the alert policy, opens no incident and pages nobody. See [Heartbeat monitors](https://statustick.com/docs/heartbeat-monitors#run-problems).

## Webhooks

StatusTick sends a JSON `POST` to your URL when an incident opens or resolves, and for cron job warnings. You can protect the endpoint with one of these:

- no authentication,
- a bearer token,
- HTTP basic authentication,
- an API key in a header you choose.

Webhook URLs must be public. StatusTick refuses private and internal addresses.

For heartbeat monitors the JSON also has:

- `problem`: the job's problem, one of `missed`, `late`, `off_schedule`, `double_fire`, `overlap`, `running_long`, `not_finished_on_time`, `lost`, `failed`. `missed`, `failed`, `not_finished_on_time` and `lost` open an incident; the others arrive with `type` `job.warning`.
- `links.run`: the run on the monitor's Runs tab (sign-in needed).

## Delivery and retries

If a channel answers with a network error or a `5xx` status, StatusTick retries up to 3 times with a growing delay. A `4xx` answer (except `429`) is not retried, because it usually means the channel is set up wrong. Every attempt is stored for 30 days, so you can see whether an alert was delivered.