# Channels (/en/docs/platform/features/alerting/channels)





A channel is a destination for notifications. Create one before writing any rules, because rules cannot be created without a channel to point at.

<Callout type="info">
  Changing channels requires the website **Manager** role.
</Callout>

## Add a channel [#add-a-channel]

**Alerts** > **Configuration** > **Add channel**. Give it a name, pick a type, and supply the destination.

The **type cannot be changed after creation**. To switch a channel from Slack to Teams, create a new one and repoint your rules.

The type list in the Add channel dialog offers all six destinations:

<img alt="The Add channel dialog with the type list open on all six destinations" src="__img0" width="1568" height="628" />

## Channel types and what each needs [#channel-types-and-what-each-needs]

Each channel type needs a different destination. Each one has a setup guide covering both the platform side and the CentralCSP side:

| Type                                                                    | What it needs                        | Required URL shape                                        |
| ----------------------------------------------------------------------- | ------------------------------------ | --------------------------------------------------------- |
| [Slack](/en/docs/platform/features/alerting/channels/slack)             | Incoming webhook URL                 | Host `hooks.slack.com`, path starting `/services/`        |
| [Google Chat](/en/docs/platform/features/alerting/channels/google-chat) | Webhook URL                          | Host `chat.googleapis.com`, path starting `/v1/spaces/`   |
| [Microsoft Teams](/en/docs/platform/features/alerting/channels/teams)   | Power Automate workflow URL          | A host under `logic.azure.com` or `api.powerplatform.com` |
| [Telegram](/en/docs/platform/features/alerting/channels/telegram)       | Bot token and chat id                | No URL                                                    |
| [Webhook](/en/docs/platform/features/alerting/channels/webhook)         | Any https URL, plus a signing secret | Public host, https only                                   |
| [Email](/en/docs/platform/features/alerting/channels/email)             | 1 to 10 addresses                    | No URL                                                    |

The URL shape is validated as you type, so a wrong-format URL is rejected before you save.

<Callout type="warn" title="Teams legacy connectors are not supported">
  Microsoft retired Office 365 connectors. Only Power Automate Workflows URLs are accepted, which is why the host must be on `logic.azure.com` or `api.powerplatform.com`. If your existing Teams webhook is an `office.com` connector URL, create a Workflow first; the [Teams setup guide](/en/docs/platform/features/alerting/channels/teams) walks through it.
</Callout>

Internal and private addresses are rejected, including `localhost`, `.local`, `.internal`, hosts with no dot, and anything resolving to a private IP range. The host is re-checked on every send, so a channel cannot be pointed at internal infrastructure after the fact.

## Email channel recipients [#email-channel-recipients]

Every recipient address must belong to a workspace member with access to the website; an outside address is rejected when you save. The [email setup guide](/en/docs/platform/features/alerting/channels/email) covers how recipients are resolved and what happens when members change.

## Webhook signatures [#webhook-signatures]

A webhook channel requires a signing secret of at least eight characters, and every delivery is HMAC-SHA256 signed. The [webhook setup guide](/en/docs/platform/features/alerting/channels/webhook) documents the payload shape, the signature headers, and verification code.

Secrets, URLs, and bot tokens are never returned by the API. Editing a channel shows a masked preview, and leaving the field empty keeps the existing value.

## Test before you rely on it [#test-before-you-rely-on-it]

**Test** sends a sample alert immediately, using a fake CSP violation event. It confirms the destination accepts messages, which is the failure you want to find now rather than during an incident.

Rate-limited to one test per channel every 15 seconds, and 20 tests per minute across the workspace.

A failed test means the destination refused the message. That is a real answer, not a transient error: check the URL, the token, and whether the receiving app is still installed.

## Channels turn themselves off [#channels-turn-themselves-off]

After **five consecutive failed deliveries** a channel switches off automatically.

To recover, fix the destination, then flip the **Enabled** switch back on. Turning it back on clears the failure count. Any successful delivery also resets the counter, so an intermittent destination does not accumulate toward the limit.

This is worth knowing because a revoked Slack webhook fails silently from your point of view: alerts stop, and nothing in the report pages changes. Check the channels list if alerts go quiet.

## Delete a channel [#delete-a-channel]

Deleting a channel stops any rule using it from delivering. Delivery history is kept, and rules that referenced it do not break.

## Next steps [#next-steps]

* Set up your destination. [Slack](/en/docs/platform/features/alerting/channels/slack), [Google Chat](/en/docs/platform/features/alerting/channels/google-chat), [Microsoft Teams](/en/docs/platform/features/alerting/channels/teams), [Telegram](/en/docs/platform/features/alerting/channels/telegram), [Webhook](/en/docs/platform/features/alerting/channels/webhook), or [Email](/en/docs/platform/features/alerting/channels/email).
* [Rules](/en/docs/platform/features/alerting/rules)
* [Delivery history](/en/docs/platform/features/alerting/deliveries)
