# Notification channels Send Tracix alerts to Slack, Microsoft Teams, PagerDuty, Opsgenie, a webhook or your email gateway, route them with policies, and hold them during downtimes. A notification channel is a destination for alerts, such as a Slack channel or a PagerDuty service. A monitor can send to channels directly, and notification policies route alerts from many monitors at once. This page shows how to add channels, route alerts to them and hold notifications during planned work. ## Supported channels Channels never store secrets themselves. Each one uses a credential from **Credentials** for its webhook URL or API key, so create the credential first. | Channel type | What you need | What Tracix sends | | ------------ | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | `slack` | A **Slack (Incoming Webhook)** credential with the webhook URL | A message to the webhook's channel | | `msteams` | A **Microsoft Teams (Webhook)** credential with an incoming webhook or Power Automate URL | A message to the channel | | `pagerduty` | A **PagerDuty** credential with an **Events Routing Key** (Events API v2) | An event that opens an incident. Recovery resolves it. | | `opsgenie` | An **Opsgenie** credential with an API key, and the EU base URL if your account is in the EU | An alert. Recovery closes it. | | `webhook` | A **Webhook URL**, and optionally a credential: header, basic or bearer authentication, or a **Webhook Signing Secret** | A JSON `POST`. With a signing secret, the body is signed in the `X-Tracix-Signature` header. | | `email` | An **Email gateway URL** and a **Recipient** | A JSON `POST` with the recipient, subject, HTML and text to your own email gateway | > **Tracix does not send email itself** > > There is no built-in mail server. The `email` channel posts each message to an HTTP endpoint you run, such as a small service in front of your mail provider, which sends the email. ## Add a channel **1. Create the credential** Open **Credentials** and create the credential the channel needs, such as **Slack (Incoming Webhook)** with your webhook URL. Webhook and email channels can skip this step if they need no authentication. **2. Create the channel** Open **Alerts › Channels**. In the **New channel** panel, enter a **Name**, choose the **Type**, fill in the fields for that type and pick the **Credential**. Select **Create channel**. **3. Send a test** Select **test** on the channel's row. Tracix sends a sample alert and shows **✓ Delivered** with the HTTP status, or the error it got back. To change a channel, delete it and create it again. Deleting a channel stops delivery to it at once; monitors that used it keep firing but deliver nowhere until you choose another channel. Creating and deleting channels needs permission to manage notification channels, which admins have by default. Tracix delivers to public addresses only: requests to private, loopback and link-local addresses are blocked, and redirects are not followed. A delivery that fails with a connection error, HTTP 429 or a 5xx response is retried up to twice. When the outcome is unknown, such as a timeout after the request went out, Tracix retries only PagerDuty and Opsgenie, which drop duplicates. Webhooks and email gateways receive an `X-Tracix-Delivery-Id` header so you can drop duplicates too. Each alert's details show how every delivery went. ## Choose where each alert goes There are two ways to send an alert to a channel. Use either or both: * **On the monitor.** Tick **Notification channels** when you create or edit a monitor. See [Monitors and templates](https://tracix.io/docs/alerting/monitors). * **With a notification policy.** A policy routes alerts from every monitor that matches it, which suits library monitors and SLO burn-rate monitors that start with no channels. ### Create a notification policy Open **Alerts › Policies**. Under **New policy**, set: | Field | What it does | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | A name for the policy, such as "page on critical". | | **monitor tags** | Optional. Comma-separated tags a monitor must carry, such as `pillar:infra`, which library monitors for infrastructure carry, or `slo` for SLO burn-rate monitors. Monitors you create with **New monitor** have no tags, so route them by severity and level instead. | | **delay** | Minutes to wait before notifying. The policy sends only if the alert is still open after the delay, so short blips never notify. 0 sends at once. | | **severity** | Any of `info`, `warning` and `critical`. | | **level** | Any of `warn`, `alert` and `no_data`. | | **channels**, **teams** | Where matching alerts go. A team sends to its own channels. | Then select **Create policy**. An empty field matches everything. Fields combine with AND, and the values you pick within one field combine with OR. Creating policies needs permission to manage on-call, which admins have by default. ### How Tracix avoids duplicate notifications * **One notification per problem and destination.** Related alerts fold into one [problem](https://tracix.io/docs/alerting/problems-and-cases), and each destination hears about the problem once, with the related alerts listed. A problem that is not critical waits up to 3 minutes so related alerts arrive together; a critical one goes at once. * **Destinations, not routes.** A monitor's channels and every matching policy and team are merged, so a channel reached by two routes gets one message. * **Recovery once.** When the problem's last alert ends, each destination that heard about it gets one recovery notice. ### Create a team A team groups channels under one name, so policies can send to "payments on call" instead of a list of channels. In **Alerts › Policies**, under **Teams**, enter a team name, pick its channels and select **Create team**. ## Hold notifications Monitors keep evaluating while notifications are held, so alert state stays accurate. Tracix applies holds in this order: downtime, snooze, a silence on one alert, then acknowledgement. ### Schedule a downtime Use a downtime for planned work, such as a maintenance window. Open **Alerts › Downtimes**, enter a name, optional **monitor tags** and an optional **entity contains…** match, the start time and the duration in minutes, and choose **once**, **daily** or **weekly**. Select **Create**. * Alerts that are still firing when the window ends notify then. Alerts that started and recovered inside the window stay quiet. * A daily or weekly downtime repeats at the same time of day in UTC. * Tick **Exclude this window from anomaly models** so the unusual data from the window does not shape anomaly baselines. ### Snooze or silence * **Snooze 1h** on a monitor's page holds all of its notifications for an hour. * **Silence…** on an alert holds that alert's notifications for 1 hour, 4 hours, 24 hours or 7 days. When a snooze or silence ends and the alert is still firing, it notifies once. ## Next steps - [SLOs and on-call](https://tracix.io/docs/alerting/slos-and-on-call): Page the person on call with escalation policies - [Problems and cases](https://tracix.io/docs/alerting/problems-and-cases): How related alerts become one problem - [Monitors and templates](https://tracix.io/docs/alerting/monitors): Choose channels per monitor