Alert Channels

When an alarm fires, people and systems are notified through an alert channel. You create channels once, centrally under Monitoring → Alert Channels, and then reference them from the alert rules of your services. One channel can serve any number of rules.

flowchart LR
    R1["Alert rule: shop down"] --> C1["Channel: On-call email"]
    R1 --> C2["Channel: #ops Slack"]
    R2["Alert rule: shop recovered"] --> C2

Click Create Channel:

Use Create & Test Alert to create the channel and immediately send a test alert through it — the fastest way to confirm the webhook URL or phone number actually works. If the provider can’t be reached, the channel is still created; you get a warning and can fix the configuration and re-test. Existing channels have a Test Alert action in the row menu and on their detail page — it works even while a channel is disabled, and shows up in the alert log with severity Test.

• Default channel — default channels are automatically pre-selected when you create a new alert rule. Toggle via Set as default in the row menu or the checkbox on the detail page.
• Enable / Disable — a disabled channel stays configured but delivers nothing. If services still reference the channel, disabling asks for confirmation and lists them.
• Duplicate — pre-fills the create form with the channel’s settings (<name> (Copy)).
• Delete — permanently removes the channel. If alert rules reference it, you’ll see a warning listing the affected services: rules that reference only this channel will no longer notify anyone.

The channel type cannot be changed after creation — create a new channel instead.

Every alert is a short title and message built from the status change: the service name, the previous and the new status, and the UTC timestamp — e.g. a transition from Operational to Major Outage. A test alert simply says that the channel works.

The severity (Info / Warning / Critical) is not a channel property — it’s set per notification step of the alert rule, so the same channel can receive a Warning from one rule and a Critical from another. Test alerts always use Test. How severity is represented depends on the channel:

Sixteen channel types are available. Quick reference — each type is described in detail below:

Sends a formatted alert email. For real alerts (not tests), the email includes a one-click Acknowledge button that stops further escalation for the current firing cycle — see acknowledging alerts.

1. Enter the recipient’s address — a shared inbox or distribution list works well for teams.
2. Create & Test Alert and check the inbox (including spam, the first time).

Sends the alert as a text message.

1. Enter the phone number in international format with country code and no leading zero, e.g. +4915123456789 (spaces, dashes, and parentheses are tolerated and stripped).
2. Create & Test Alert — the test text should arrive within seconds.

To keep message volume under control during long outages, cap the escalation step’s Max. repeats in your alert rules.

Calls the number and reads the alert out loud (text-to-speech) — the channel that wakes people up when a push notification won’t.

1. Enter the phone number in international format, e.g. +4915123456789.
2. Create & Test Alert — you’ll receive a call announcing the test alert.

Same advice as SMS: use Max. repeats on escalation steps to limit repeated calls.

Delivers the alert as a JSON POST to any endpoint you run — the integration point for everything that has no dedicated channel type.

{
  "title": "Service 'Shop' change status to 'Major Outage'",
  "message": "The status of the service 'Shop' change from status 'Operational' to 'Major Outage' on '2026-07-16T09:41:00Z UTC'",
  "severity": "CRITICAL"
}

• Additional payload data (key/value) is merged into the JSON body — handy for routing hints like {"env": "prod"}. The reserved fields title, message, and severity always win on collision.
• Custom HTTP headers are sent with every delivery — e.g. an Authorization header your endpoint requires.
• Every request also carries TC-Webhook-Id, TC-Webhook-Event: monitoring.alert.triggered, and TC-Webhook-Timestamp headers (these override same-named custom headers).
• Your endpoint has 10 seconds to respond; any 2xx counts as delivered.

Setup:

1. Expose an HTTPS endpoint that accepts a JSON POST and returns 2xx (http is allowed for internal systems).
2. Paste the URL, add any headers or extra payload fields, and Create & Test Alert — then check your endpoint’s log for the severity: "TEST" request.

Posts the alert as a message into a Slack channel via an incoming webhook.

1. Open api.slack.com/apps → Create New App → From scratch → name it (e.g. “TrustComponent Alerts”) and pick your workspace.
2. In the app’s settings, open Incoming Webhooks, switch Activate Incoming Webhooks on, then click Add New Webhook to Workspace and choose the target channel.
3. Copy the webhook URL — it must be on hooks.slack.com (e.g. https://hooks.slack.com/services/T…/B…/…); other hosts are rejected.
4. Paste it into Webhook Url and Create & Test Alert — the test message appears in the chosen channel.

Posts the alert into a Discord channel.

1. In Discord, open Server Settings → Integrations → Webhooks → New Webhook.
2. Name it, pick the target channel (avatar and color are up to you), then Copy Webhook URL.
3. Paste the URL (https required) and Create & Test Alert.

Posts the alert as an Adaptive Card into a Teams channel, color-coded by severity. Teams receives it through a Power Automate workflow — the successor of the retired Office 365 connectors, so use a workflow URL, not a legacy webhook.office.com connector. Workflows require a Microsoft 365 work or school account — they’re not available in the personal (free) version of Teams.

1. In Teams, open the target channel → ⋯ (more options) → Workflows.
2. Choose the template “Post to a channel when a webhook request is received”, confirm team and channel, and add the workflow.
3. Copy the HTTP URL the workflow shows you (typically on …logic.azure.com).
4. Paste it into Webhook Url (https required) and Create & Test Alert — the card is posted by the Workflows bot.

Sends the alert as a plain-text message from your own Telegram bot.

1. In Telegram, message @BotFather, send /newbot, and follow the prompts — copy the bot token (123456789:AA…).
2. Open your new bot’s chat and press Start — or, for a group, add the bot to the group and post a message. A bot can only message chats that have contacted it first.
3. Open https://api.telegram.org/bot<TOKEN>/getUpdates in a browser and read chat.id from the response (group IDs are negative, e.g. -1001234567890). Empty response? New messages can take a few minutes to show up — send another one and reload.
4. Enter bot token and chat ID, then Create & Test Alert.

Triggers a PagerDuty incident through the Events API v2.

1. In PagerDuty, open Services → your service → Integrations → Add an integration → select Events API V2.
2. Copy the 32-character Integration Key, paste it, and Create & Test Alert (the test arrives with severity info).

Creates an Opsgenie alert with a severity-mapped priority (see the severity table).

1. In Opsgenie, open Settings → Integrations (or Teams → your team → Integrations) → add an API integration with Create and Update Access enabled.
2. Copy the API key.
3. As Api Url, use https://api.opsgenie.com — or https://api.eu.opsgenie.com if your Opsgenie account is EU-hosted.
4. Optionally set a team (added as responder), comma-separated tags attached to every alert, and a custom source (default: monitoring).
5. Create & Test Alert — the test arrives as priority P5.

Sends the alert to a Zapier Catch Hook, from where a Zap can route it anywhere Zapier connects to.

1. In Zapier, create a new Zap with trigger Webhooks by Zapier → event Catch Hook.
2. Copy the generated webhook URL (https://hooks.zapier.com/hooks/catch/…).
3. Paste it (https required) and Create & Test Alert — the test request gives Zapier a sample record with the fields title, message, and severity to map in your action steps.

Sends the alert to Splunk’s HTTP Event Collector (HEC); it arrives as an event with title, message, and severity fields.

1. In Splunk, open Settings → Data inputs → HTTP Event Collector → New Token and complete the wizard. If HEC is disabled, enable it under Global Settings first (default port 8088).
2. As Hec Url, enter the full collector endpoint — self-hosted: https://splunk.example.com:8088/services/collector/event; Splunk Cloud: https://http-inputs-<stack>.splunkcloud.com/services/collector/event.
3. Paste the generated token. Optionally override the index (otherwise the token’s default index applies), source (default monitoring), and sourcetype (default _json).
4. Create & Test Alert, then search your index for the test event.

Posts the alert into a Mattermost channel via an incoming webhook.

1. In Mattermost, open the product menu (grid icon) → Integrations → Incoming Webhooks → Add Incoming Webhook and pick the target channel. (If Integrations is missing, a system admin must enable incoming webhooks first.)
2. Copy the webhook URL and paste it — plain http:// is accepted for self-hosted instances on internal networks.
3. Create & Test Alert.

Posts the alert into a Google Chat space (webhooks are a Google Workspace feature and not available in direct messages).

1. In Google Chat, open the space → click the space name → Apps & integrations → Webhooks → Add webhook.
2. Name it and copy the generated URL (https://chat.googleapis.com/v1/spaces/…).
3. Paste it (https required) and Create & Test Alert.

Sends the alert as a push note to one of your devices — or to a Pushbullet channel.

1. On pushbullet.com, open Settings → Account → Create Access Token and copy it.
2. Find your device iden by listing your devices: curl -H "Access-Token: <token>" https://api.pushbullet.com/v2/devices — copy the iden of the target device.
3. Optionally set a channel tag — if set, the alert is pushed to that Pushbullet channel instead of the device.
4. Create & Test Alert.

Sends the alert as a Pushover notification to your devices.

1. Log in at pushover.net — your User Key is shown right on the dashboard.
2. Scroll to Your Applications → Create an Application/API Token, name it, and copy the generated API token.
3. Enter token and user key, then Create & Test Alert.

Alerts are delivered at Pushover’s normal priority regardless of severity.

• Chat and incident-management channels (Slack, Discord, Teams, Telegram, PagerDuty, Opsgenie, Zapier, Splunk, Mattermost, Google Chat, Pushbullet, Pushover) are called directly, with up to 3 attempts — retried on HTTP 429, 5xx, and network errors. Any 2xx response counts as delivered.
• E-Mail, SMS, Voice Call, and Webhook run through the TrustComponent notification pipeline: up to 5 attempts with increasing backoff (from about a minute up to several hours), so a temporarily unreachable endpoint still gets the alert.
• Channels are notified independently and in parallel — one failing channel never delays or blocks the others.
• Disabled channels are skipped entirely (test alerts excepted).

The detail page of every channel shows its latest alerts — timestamp, severity, title, and message of each delivery — and the channels list shows when each channel was last used. To see alerts across all channels, use the Alerts page.

• The number of channels is a plan limit — the badge on the channels page shows your usage, e.g. 2 / 5 channels.
• Available channel types depend on your plan; types outside your plan simply don’t appear in the type dropdown.
• Two channels with the identical configuration (same type and destination) are rejected — duplicate the name instead, or reuse the existing channel in more rules.
• Creating, editing, testing, and deleting channels requires the member or admin role.