---
title: Notification Routing
description: Route stack alerts to specific Discord, Slack, or webhook channels with per-stack routing rules.
---

<Note>
  Notification Routing requires a **Sencho Admiral** license. Community and Skipper users can configure global notification channels in **Settings > Notifications**.
</Note>

Notification Routing lets you direct alerts from specific stacks to dedicated channels. Instead of all alerts going to a single global endpoint, you can send production alerts to one Slack channel and staging alerts to another.

<Frame>
  <img src="/images/notification-routing/notification-routing-overview.png" alt="Notification Routing settings showing the empty state with Add Route button" />
</Frame>

## How routing works

When Sencho dispatches an alert (container crash, threshold breach, scheduled task failure), the routing engine:

1. **Checks routing rules** sorted by priority (lowest number first). If the alert's stack matches a rule's stack list, the notification is sent to that rule's channel.
2. **Falls back to global channels** if no routing rule matches (or the alert has no stack context, such as host resource warnings). Global channels are configured in **Settings > Notifications**.

Routing rules and global channels are independent. A matched route **replaces** the global dispatch for that alert; it does not send to both.

## Creating a routing rule

1. Go to **Settings > Routing**
2. Click **+ Add Route**
3. Fill in the form:

<Frame>
  <img src="/images/notification-routing/notification-routing-dialog.png" alt="New Routing Rule dialog with Name, Stacks, Channel, Priority, and Enabled fields" />
</Frame>

| Field | Description |
|-------|-------------|
| **Name** | A label for this rule (e.g. "Production to Discord") |
| **Stacks** | One or more stacks this rule applies to. Use the searchable dropdown to find and add stacks. Selected stacks appear as removable pills below the dropdown. |
| **Channel** | Choose Discord, Slack, or Webhook using the tab bar, then enter the endpoint URL. The URL must use HTTPS. |
| **Priority** | Lower values are evaluated first. Default is 0. |
| **Enabled** | Toggle the rule on or off without deleting it |

4. Click **Create** to save the rule

## Managing rules

Each routing rule appears as a card showing the rule name, channel type badge, assigned stack pills, the channel URL (truncated), and priority (when non-zero).

From the rule card, you can:

- **Toggle** a rule on/off with the switch
- **Test** a rule by clicking the lightning bolt icon, which sends a test notification to the rule's channel
- **Edit** a rule by clicking the pencil icon
- **Delete** a rule via the trash icon (with a confirmation dialog)

## Priority and matching

Rules are evaluated in ascending priority order. If multiple rules match the same stack, **all matching rules fire**. This lets you send the same alert to multiple channels (e.g. both a Slack channel and a custom webhook).

If any rule matches, global channels are skipped for that alert.

## Fallback behavior

Alerts without a stack context always use global channels. These include:

- Host CPU, memory, and disk threshold warnings
- Docker data accumulation notifications

Stack-scoped alerts that do not match any routing rule also fall back to global channels.

## Example setup

**Scenario:** You want production stack crashes in `#prod-alerts` on Slack, and all staging stacks in a Discord channel.

| Rule | Stacks | Channel | Priority |
|------|--------|---------|----------|
| Prod to Slack | `prod-api`, `prod-web` | Slack | 0 |
| Staging to Discord | `staging-api`, `staging-web` | Discord | 10 |

Any other stack alerts (e.g. `dev-tools`) would fall back to your global notification channels.