Channels

You've drafted a Rule and a Policy, and now you need somewhere for the alert to land. A Channel is the destination — a Slack webhook URL, an email address, an HTTPS endpoint, or the in-app inbox. This page covers what each kind needs, when to use which, and how to test a new destination before relying on it.

The four channel kinds

Three of the four (slack, email, webhook) are user-configured on the Channels page. The fourth, in_app, is a system channel — it's not something you create or edit. You opt into in-app delivery by setting a Policy's delivery mode to in_app_only. See Policies.

Slack

Required config:

• Destination: a Slack incoming-webhook URL.
• Must start with https://hooks.slack.com/. The editor enforces this.

Generate the webhook in Slack at Apps → Incoming Webhooks → Add to Slack, pick the channel you want alerts to post into, and copy the URL. Paste into the Channel editor's Destination field. The Kubeadapt-side name is whatever you want to call it ("#alerts-prod", "#finance-budgets").

Use when: the team responsible for the alert lives in Slack and you want a low-friction, conversation-ready notification.

Limits: Slack's webhook rate limit applies (1 request per second per webhook). For a high-volume Policy, batch with daily_digest delivery mode or split across multiple webhooks.

Email

Required config:

• Destination: a single, valid email address.
• Validated against a standard email regex.

Use a distribution list address (e.g., finance-alerts@yourcompany.com) rather than a single person. People rotate; lists don't.

Use when: the audience reads email, when an audit trail in an inbox is useful, or when the team has no Slack workspace.

Limits: Email delivery is best-effort. Kubeadapt sends through its mailer; spam filters on your end can still drop messages. Test the channel after creation (see below) and check the inbox.

Webhook

Required config:

• Destination: any HTTPS URL.
• Optional: basic auth username + password.

Kubeadapt POSTs a signed JSON payload to the URL when an alert fires. The payload includes the incident ID, the rule, the scope, the firing condition, and the timeline. The shape is documented under the Webhook payload reference when published.

Use when: you have an internal incident system, PagerDuty, Opsgenie, or any service that takes a webhook. The same channel can be reused across multiple Policies.

Security: the request is signed; verify the signature on your end before processing. The basic-auth fields are an additional optional layer.

In-app

Required config: none. The in-app channel is system-managed and always available.

How to enable: set a Policy's delivery mode to in_app_only. Every alert routed by that Policy lands in the dashboard inbox. Users in your tenant see the inbox count update without leaving the app.

Use when: you want a low-noise channel for informational alerts that don't need to interrupt anyone, or as a redundant destination alongside external channels. Some teams add in_app_only to a digest Policy so the inbox stays a complete record even when Slack is on Do Not Disturb.

Limit: the inbox is per-tenant, not per-user. Every user with access to Smart Alerting sees every in-app alert.

Channel health

Every Channel has a status:

• healthy — recent deliveries succeeded.
• degraded — recent deliveries are slow or partially failing. The Channel still receives traffic; investigate the destination.
• failing — recent deliveries consistently fail. New alerts continue to attempt delivery but back off.

The Channels page shows the breakdown across all configured channels at the top, and tags each row with its status badge. A failing Slack webhook usually means the webhook was revoked in Slack; a failing email usually means the recipient address bounced.

Testing a channel

After creating or editing a Channel, the editor offers a Test channel button (on existing channels) that delivers a single test notification with the same path the real alerts will use. The result toasts immediately: delivered, attempted-but-failed with reason, or not-attempted-due-to-config.

The test is a real send. Slack will get a real "Kubeadapt test alert" message; webhooks will receive a real POST with test: true in the payload. Run a test the first time you wire a new destination, and after every change to the URL or address.

Renaming and deleting

• Renaming is a label-only change. The destination URL or address stays the same; nothing downstream notices.
• Deleting a Channel removes it from your tenant. Policies that referenced the deleted Channel keep the chip in their config (so existing rules still serialize cleanly), but the editor highlights it as missing on next open. Delete and re-add a Channel only when you've updated every Policy that references it.

What's not here

• No per-rule channel selection. Channels attach to Policies, not Rules. Rules pick a Policy; the Policy decides the Channels.
• No SMS or voice channels. Use a webhook into a service that handles SMS (Twilio, OpsGenie, PagerDuty) instead.
• No Microsoft Teams native integration. Use the generic webhook with a Teams incoming-webhook URL.
• No custom payload templates. The Slack and webhook payloads are versioned; check the reference for the current shape.

Next steps

• Policies — pick a delivery mode, daily cap, and time window for the Channels you've configured.
• Rules — attach the Policy that owns these Channels.
• Smart Alerting overview — the full mental model.