Alert Channels
Send campaign alerts to Slack, Microsoft Teams, Google Chat, Discord, Telegram or your own webhook, route them per project, and choose which alerts reach you.
Alerts always land in the campaign’s alert feed. Beyond that, they can reach people three ways: email and in-app notices for members, chat spaces your team already reads, and webhooks into your own systems. This page covers the second and third, and how each member chooses what reaches them.
Channels carry alerts from every alerting tool: SERP Position Tracker, Ads Position Tracker, Maps Visibility, Marketplace and AI Visibility.
Who receives alerts by email and in the app
Section titled “Who receives alerts by email and in the app”- Owners receive every alert by default, as before: in-app straight away, by email at most once an hour. They can narrow this under My alerts like anyone else.
- Admins and members opt in under Settings → Account → My alerts. Each person picks email and/or in-app, a minimum severity, and optionally which projects. They only ever receive alerts for projects they can access.
- Anyone can turn alert emails off entirely in their notification preferences.
Chat and webhook destinations
Section titled “Chat and webhook destinations”A destination is one place alerts are posted: a Slack channel, a Teams channel, a Google Chat space, a Discord channel, a Telegram chat, or a webhook endpoint. Destinations are saved once for the organization under Settings → Alerts & channels and then used by any number of campaigns.
| Destination | How you connect it |
|---|---|
| Slack | Connect your workspace once, then pick a channel. Invite the app to private ones. |
| Microsoft Teams | Paste the address of a Teams Workflows webhook (“Send webhook alerts to a channel”). |
| Google Chat | Paste the incoming-webhook address of a space. |
| Discord | Paste the webhook address from the channel’s integrations settings. |
| Telegram | Open the link the app gives you and start the bot, in a private chat or a group. |
| Webhook | Paste a public HTTPS endpoint. Payloads are signed — see Webhooks. |
Owners and admins add, change and remove destinations and routes; members can see them. A custom role gets these rights only when they are granted in the role editor.
Every destination has a Send test button. Use it before relying on a new one. A route, and a campaign’s own choice, can each send to up to 10 destinations.
How messages arrive
Section titled “How messages arrive”- Chat destinations collect alerts for about a minute and post them together: one card for a single alert, or a short list of the first five with a count of the rest. A burst of alerts after a run is one message, not twenty.
- Webhooks get one request per alert, straight away.
- In Google Chat, a campaign’s alerts of one day share a thread.
- In a Telegram group with topics, alerts go to the General topic. To use another topic, open
it and send
/start@<bot> <code>there instead of tapping the link, with the code from the end of the link the app gives you. - Each destination writes its messages in one language. Leave Message language on Your language and a new destination uses your account’s language (English if it has none), or pick one. A destination without a language is written in English.
Where a campaign’s alerts go
Section titled “Where a campaign’s alerts go”Alerts follow routes:
- The campaign’s own choice. In a campaign’s alert settings, Send to can name specific destinations instead of following routing. Choosing none sends that campaign’s alerts nowhere outside the app, email and the campaign’s own webhook URL. If every destination it named has since been deleted, its alerts go nowhere either, rather than falling through to shared channels.
- The project’s route (plans with per-project routing). A project can have a route of its own, with its own destinations and minimum severity. It replaces the organization default for campaigns in that project, so one client’s alerts never reach another client’s channel. Switch on Also send to the default route to post to both.
- The organization default. Everything else goes to the default route’s destinations.
On plans with per-campaign Send to, the field shows which destinations routing sends the campaign’s alerts to before you save, marks any that is not receiving right now, and says when the route only passes alerts of a minimum severity.
When a destination stops working
Section titled “When a destination stops working”Temporary failures (timeouts, server errors) are retried automatically, a few times over several minutes. When a receiver asks us to slow down, we wait as long as it asks before trying again; one that keeps asking is treated as failing. A delivery that still fails is given up on and recorded, and an alert that still has not gone out after 24 hours is dropped rather than delivered late.
A destination is set aside — marked Needs attention — when the receiver says it no longer exists or refuses us (a deleted channel, a revoked webhook, a removed bot, a disconnected Slack workspace), or after five deliveries in a row have been given up on (one chat message can carry several alerts). A destination at an address you pasted (webhook, Discord, Google Chat or Teams) answering “not found”, “unauthorized” or a redirect is given three chances in a row first, spread over about a quarter of an hour, since a deploy or a proxy can answer that for a moment. Owners and the person who set the destination up get an email and an in-app notice when that happens. Fix the cause, then Resume the destination in Settings → Alerts & channels. Saving a new address or channel for it puts it back in service as well; a Slack destination whose workspace was disconnected offers Reconnect instead.
A destination is marked Not in your plan when the organization’s plan no longer includes it, and resumes by itself when the plan allows it again. Both happen when the next alert is routed, so the label can lag a plan change until then. Alerts raised meanwhile are skipped, not queued.
Each destination keeps a log of what was sent, kept for 90 days. It is not shown in the app: support reads it when you ask why an alert did not arrive.
| Feature | Available on |
|---|---|
| Email and in-app alerts, and a webhook URL on each campaign | Every plan |
| Chat and webhook destinations, and alert routing | Plans that include alert channels |
| Per-campaign Send to | Plans that include choosing per campaign |
| Per-project routing | Plans that include per-project routing |
A plan with alert channels also sets which destination types you can add and how many destinations you can save; Settings → Alerts & channels shows how many you have left. Plans and pricing lists which plans include each feature. The campaign’s own webhook URL keeps working on every plan, in the same format as before.
If the plan stops including per-project routing, existing project routes still keep those projects’ alerts out of the shared default route (unless the route also sends to the default route), so no client’s alerts reach another client’s channel. Their chat destinations stop receiving them; email and in-app are unaffected. Delete a project route to send its project’s alerts to the default route again.
The same holds for a campaign that chose its own destinations: if the plan stops including that choice, the campaign’s alerts stay out of shared channels. Its alert settings say so; choose Follow alert routing there to send them to the routes again.
Open in iSearchFrom
Section titled “Open in iSearchFrom”Open Alerts & channels in the app to add destinations and routes, or Account settings for My alerts.