> ## Documentation Index > Fetch the complete documentation index at: https://docs.tallwatch.com/llms.txt > Use this file to discover all available pages before exploring further. # Alerts > Connect Tallwatch to Slack, Discord, Teams, Telegram, email, PagerDuty, or a webhook, and decide which monitors send where. When an incident opens or resolves, Tallwatch sends an alert. A channel is one place an alert can go. You add channels, then decide which monitors use which channels through escalation policies. ## Connect a channel Each channel is a short form: pick the type, paste the credentials it needs, and click **Send test alert** to confirm it works before you rely on it. Up to 50 recipients per channel. An incoming webhook URL. A server webhook URL. A Workflows webhook. A bot token and chat ID. An Events API v2 integration key. A signed POST to your own endpoint. Not sure which to use? Use Slack, Discord, or Teams, whichever your team keeps open all day. Use PagerDuty, or an [on-call schedule](/on-call) targeting an email or chat channel. PagerDuty owns the rotation, mobile push, and SMS at the device layer. Use email with a distribution list. The thread outlives whatever chat tool you switch to later. Use a [webhook](/alerts/webhook). Verify the signature, read the payload, and route it however you like. ## Where alerts go by default Every workspace starts with a [Default Alerts](/alerts/default-alerts) email channel seeded with your address. A monitor with no escalation policy falls back to every enabled channel, so a new account gets alerts without any routing setup. Once you have more than a channel or two, set up routing. ## Route alerts to the right people Two pieces decide who hears about what: Ordered levels that keep paging wider until someone acknowledges. Rotations and overrides, so a policy can page whoever is on call right now. ## How delivery behaves A few things hold across every channel: * **Alerts send immediately.** There's no artificial delay or rate limit on Tallwatch's side. If a destination like Slack throttles a burst, that's its own limit, not ours. * **Transient failures retry.** A 5xx, a 429, or a network blip is retried a few times in place before the dispatch is marked `failed` on the incident. * **No duplicates.** The same incident event never sends twice to the same channel. If a channel breaks (a revoked webhook, a deleted Slack channel), the dispatch shows as `failed` on the incident with the exact error. Fix the channel and the next incident event delivers normally; past failures stay on the record as `failed`.