Notification channels

A notification channel is a destination where alerts land. You create a channel once, then attach it to your alert rules so firings are routed there. Channels are managed under Admin → Notifications.

Channel types

CloudQuell supports three channel types:

Email — sends alerts to one or more email addresses. Recipients don’t need CloudQuell accounts — a channel can list any address (a teammate, a shared inbox, a distribution list).
Slack — posts to a Slack channel via an incoming webhook.
Microsoft Teams — posts to a Teams channel via an incoming webhook.

Creating a channel

Creating, editing, testing, and deleting channels are Admin actions (Admin or Super Admin). Contributors can see the channels that exist and attach them to their own alert rules and team report emails, but they can’t create or remove channels — ask an Admin to add one.

To create a channel you give it a name, choose its type (email, slack, or teams), and provide a destination:

For an email channel, the address(es) to deliver to.
For a Slack channel, an incoming webhook URL created in your Slack workspace for the channel you want alerts in.
For a Teams channel, an incoming webhook URL created on the Teams channel (via Workflows or an incoming-webhook connector).

An agent connected through the MCP server creates channels with create_notification_channel. Creating, testing, and deleting channels are write actions, so they require the admin:write scope and an explicit confirmation on each call.

Testing a channel

After creating a channel, send a test message to confirm it’s wired up correctly.

Via MCP this is test_notification_channel. If the test doesn’t arrive, check the destination URL or address and that the receiving app still accepts the incoming webhook.

Attaching channels to a rule

You attach channels when creating or editing an alert rule. A rule can deliver to several channels at once — up to one each of email, Slack, and Teams. Picking a second channel of the same type replaces the first. To email more people from one rule, add their addresses to the email channel rather than creating extra channels.

Unsubscribing from alert emails

Every email sent by an alert rule carries a one-click unsubscribe link (and the standard unsubscribe header your mail client surfaces). Emails from budget threshold crossings don’t carry one — manage those recipients on the budget itself. Unsubscribing suppresses that address for that alert rule only — other recipients and the rule’s Slack or Teams delivery are unaffected.

Recipients do not need a CloudQuell account: the link works for everyone the alert is sent to. The opt-out is durable — it survives the rule being edited or the address being re-added — until that person explicitly re-subscribes. Members can toggle their own alert emails from the rule card’s bell icon, or from Notification preferences in the account menu (also under Profile → Email preferences) — every role, including Viewers. If an unsubscribe leaves a rule with no remaining delivery targets at all, the rule is paused automatically so it doesn’t fire into the void.

Removing a channel

Deleting a channel stops it from receiving any further alerts — and permanently deletes every alert rule that delivers to it. If you want to keep a rule, detach the channel from it (or attach a different channel) first. Via MCP this is delete_notification_channel, which also requires confirmation and reports how many alert rules were removed with the channel.

Alerts overview — how channels fit into alerting.
Alert rules — attach channels to rules and read firing history.