Documentation / Alerting / Channels

Channels

Named delivery endpoints — Email, Microsoft Teams, Slack, or your own HTTPS endpoint — that rules dispatch notifications to. Configure each one once, then reference it from as many rules as you need.

On this page

A channel is the where half of an alert. Rules decide which events match; channels decide where matched events are delivered. Splitting the two means a single delivery destination — say, your finance team's Slack — can be wired into multiple rules without duplicating its configuration.

The Channels tab

Open Organisation Settings → Alerting and switch to the Channels tab. The page lists every delivery endpoint configured for the organisation. Each row shows:

  • Name — a human-readable label that you'll later pick from in rules. Click the name to open and edit the channel.
  • Type — Email, Microsoft Teams, Slack, or Custom webhook.
  • Status — Enabled or Disabled. See Enabling and disabling.

The row menu (⋮) offers Edit, Send test, and Delete. Click Add channel at the top right to create a new one.

Common fields

Every channel takes a few fields regardless of type:

  • Channel name — required. Pick something descriptive — you'll see this label in the rule editor's channel picker and in delivery history. Examples: "Finance team Slack", "Platform on-call email", "SIEM webhook".
  • Type — Email, Microsoft Teams, Slack, or Custom webhook. The remaining fields adapt to whichever you pick.
  • Enabled — a checkbox. New channels default to enabled.

Email

Add one or more email recipients. Each address becomes a chip — use the Add recipient button after each one. Recipients don't need to be Cirrova users; any valid email address works, so distribution lists, ticket-system inboxes, or shared mailboxes are all fine.

Prefer a distribution list or ticket-system address over individual people. When the on-call rotation changes, you only need to update the list once rather than re-edit channels in Cirrova.

Microsoft Teams

Paste a Microsoft Teams Workflows webhook URL into the Incoming webhook URL field. To create one inside Teams:

  1. Open the target channel in Teams.
  2. Click the channel options (…) and select Workflows.
  3. Choose the Post to a channel when a webhook request is received template.
  4. Pick the destination team and channel, then save. Teams shows the generated webhook URL.

Save the channel in Cirrova and run Send test from the row menu to confirm the webhook is reachable before wiring it into any rule.

Microsoft retired the older Incoming Webhooks connector in favour of Workflows. New URLs should be Workflows webhooks; legacy connector URLs may still work but are not recommended.

Slack

Paste an incoming webhook URL from your Slack workspace into the Incoming webhook URL field. To create one:

  1. From your Slack workspace, open Apps and search for Incoming Webhooks.
  2. Click Add to Slack, pick the destination channel, and authorise.
  3. Slack generates the webhook URL — copy it.

Save the channel and run Send test to confirm.

Custom webhook

Use a custom webhook when you want Cirrova events to flow into your own systems — a queue, an internal API, a SIEM, an audit pipeline, an automation runner — rather than a chat tool. The full integration spec, including signature verification, retry behaviour, and per-event payload schemas, lives on its own page: Custom webhooks.

The fields on the channel are:

  • Endpoint URL — the HTTPS endpoint Cirrova will POST events to. HTTP endpoints are rejected — TLS is required.
  • Signing key (optional) — a shared secret used to compute the X-Cirrova-Signature HMAC header on every delivery. Set this and verify the header on your end so your endpoint can prove a request really came from Cirrova. Cirrova shows the value when you create or rotate it; store it in a secret manager.
  • Custom headers (optional) — arbitrary key/value pairs added to every request. Useful for an authentication header your endpoint expects, a routing tag, or a tenant identifier.
Sign your webhooks. Without a signing key, anyone who learns your endpoint URL can fabricate events. Configure the signing key when you create the channel and verify the signature on every request — see Signature verification.

Enabling and disabling

Disabling a channel stops it being used by any rule, without having to remove it from rules individually. Disabled channels still appear in the rule editor's channel picker (so you can see they exist), but rules that reference them won't deliver until the channel is re-enabled.

Disabling is useful for:

  • Temporary mute — silence a Slack channel during a known noisy window without rewiring rules.
  • Rotation — disable a channel that's owned by someone on holiday and re-enable when they're back, with no risk of forgetting which rules pointed at it.
  • Staged rollout — create the channel, leave it disabled while you build out the rules, then flip it on once you're ready for live deliveries.

Deletion is more permanent: the channel is removed from every rule that references it. If a rule ends up with no channels after a deletion, it stops delivering anywhere — re-edit the rule to add a replacement.

Send test

The row menu's Send test action dispatches a sample test event to the channel. Use it to confirm:

  • The endpoint or webhook URL is reachable.
  • Email addresses are spelled correctly and not bouncing.
  • For custom webhooks: your signature verification logic accepts a real Cirrova request.

The test event uses the same headers and signing as a production delivery, so it's a faithful probe rather than a simplified ping. For custom webhooks, the test payload schema is documented at test.

Test deliveries are not retried on failure — they're a one-shot probe. If the test fails, fix the issue and try again rather than waiting for an automatic retry.
Previous Alerting Next Rules