Routing Rules

Routing rules decide which channels get notified for which alerts. They govern every alert notification, both individual alerts and correlated alert groups. Each rule matches alerts by their labels; the first matching rule wins and sends those alerts to its destination channels. Whether the matched alerts notify one by one or fold into a single Alert Group comes down to the rule’s Alert grouping setting: deterministic group-by keys in Static mode, or the correlation engine in Auto (AI) mode.

Not the incident routing rules

This page routes alert notifications to channels. To control how an alert becomes an incident inside Incident Management (its service, escalation policy, and severity), see Incident Management → Routing Rules instead.

Routing rules replace the older Notification Policies flow. If you previously routed by tags, KloudMate migrated those policies to routing rules during the upgrade; the matching logic now keys off labels instead of free-form tags.

Where to find them

Open Alerts → Routing rules. Rules are evaluated in priority order (lowest number wins). The first rule an alert matches decides which channels notify and how often, and whether the alert notifies on its own or correlates with others into one Alert Group.

Rules are sorted by priority, lowest number first. The default passthrough rule matches everything no higher-priority rule caught, and it can’t be deleted.

Anatomy of a rule

A routing rule has these fields:

Field	What it does
Name	How the rule appears in the list and audit log.
Priority	Lower numbers win. When an alert matches multiple rules, the highest-priority (lowest-numbered) rule routes it.
Matchers	Label conditions that pick which alerts this rule applies to.
Group-by	In Static grouping, whether and how matched alerts correlate. Leave it empty (or set only alarm_id) for one notification per alert rule, with no grouping. Add a real label key (for example service) to correlate matching alerts that share that value into one Alert Group. severity can’t be used here. This field is ignored when the rule uses Auto (AI) grouping.
Notification timing	When the first notification goes out (Group wait), the minimum gap between notifications when the group changes (Group interval), and how often to re-send while the group stays open and unchanged (Repeat interval).
Destination channels	One or more notification channels that receive the dispatched payload.

Optional:

• Auto-RCA: toggle to run KloudMate’s AI investigator on every group this rule opens. See Auto-RCA.

Matchers

Each matcher is one label condition: a label key, an operator, and a value. An alert has to satisfy every matcher you add (they combine with AND) before this rule handles it. Leave the list empty and the rule becomes a catch-all: it handles every alert no higher-priority rule already caught.

The available operators:

Operator	Meaning
Equals	Label value matches the string exactly.
Not equals	Label value differs from the string (also matches alerts that don’t carry the label at all).
Matches regex	Label value matches the regular expression.
Doesn’t match regex	Label value doesn’t match the regex (also matches alerts without the label).

A matcher value is always a single string. To match any of several values, use a regex alternation. For example, service Matches regex api|web matches either service. (There’s no in/not_in operator; the regex form replaces it.)

As you add or edit matchers, the editor shows a live Affected Alert Instances preview: the alert instances this rule currently matches, with a running count, so you can confirm the rule’s scope before saving.

Alert grouping: Static or Auto (AI)

Each rule has an Alert grouping control, and it defaults to Static.

• Static groups matching alerts by the label keys you choose, the deterministic behavior described under Group-by keys below. Alerts that share those key values fold into one group.
• Auto (AI) hands grouping to the correlation engine. It correlates related alerts from this rule into a single incident on its own, and learns which alerts tend to fire together over time. In this mode you don’t choose grouping keys at all.

Leave a rule on Static when you want predictable grouping along keys you control. Switch it to Auto (AI) when related alerts don’t share a clean label to group on, or when you’d rather let the engine find the connections. Either mode produces the same Alert Group.

For how each mode decides what belongs together, including why one rule firing on many hosts stays a single Auto group, see How Alert Grouping Works.

Group-by keys

Group-by keys apply in Static mode. They decide whether matched alerts correlate and, if so, along which dimension:

• Leave it empty, or set only alarm_id, and the rule doesn’t correlate anything: each alert rule notifies on its own, one notification per rule. These notifications surface through the normal alerts UI, not the Alert Groups page.
• Add a real label key and matching alerts that share that key’s value fold into a single alert group. The editor suggests common keys (service, env, host, region, team, issue_id, check_id, alarm_rule_folder_id), and you can type any other label key.

The editor enforces these constraints:

• If you add a real dimension alongside alarm_id, KloudMate drops the alarm_id automatically. Pinning each group to a single alert rule would defeat the correlation.
• severity can’t be a grouping dimension. It’s a per-instance property fixed when the group opens, not an axis to group on.

You can combine keys (for example, service + env) to scope each group tightly. Pick keys by which dimension changes the most: aggressive grouping (only service) reduces notification noise but sacrifices precision in the group title.

Notification timing

Notification timing decides when the first notification goes out and how often the rule follows up. Enter each setting as duration text, such as 30s, 5m, or 4h.

Setting	Default	What it controls
Group wait	30s	How long to wait before the first notification, so alerts that fire together share one message.
Group interval	5m	The minimum gap between notifications when the group changes, such as a new alert joining or an instance recovering. It’s driven by those changes, so it never fires on its own.
Repeat interval	0 (off)	How often to re-send while the group stays open and nothing about it changes.

Repeat interval

Group interval only fires when the group changes, so a group whose instances keep firing goes quiet after the first notification. An alert that starts at 02:00 and is still firing at 09:00 has produced exactly one message, seven hours earlier.

Set a Repeat interval and the rule re-sends the notification at that cadence for as long as the group stays open. Every rule starts at 0, which is off, so nothing changes until you set a value. A blank field reads as off too. The shortest cadence you can set is 5m, and the form rejects anything shorter unless it’s 0.

Reminders stop on their own when the group resolves. A silenced group doesn’t get them, and it doesn’t build up a backlog to deliver once the silence ends. A group that opened while it was already silenced was never announced, so it gets no reminders at all.

Slack, email, Microsoft Teams, webhook, and SNS deliver reminders. Jira and KloudMate Incidents don’t. The ticket or the incident is already a standing record that the alert is open, so a comment on it every few hours would only add noise. A rule that routes only to those two sends nothing extra when a reminder is due.

In Slack, the reminder posts as a reply in the alert’s existing thread and is broadcast to the channel, so you see it in the channel instead of buried under an hours-old parent message.

Check your webhook receivers first

A reminder is delivered with "event": "repeat" in the payload. Everything else about it matches an appended notification: the same totals, the same rules. A receiver that treats every incoming POST as a new alert will raise a duplicate every time a reminder fires. Handle or ignore repeat explicitly before you turn this on. See Notification Payloads.

The default passthrough rule

Every workspace has a default passthrough rule. It matches everything that didn’t match a higher-priority rule. You can edit its destination channels and notification timing, but you can’t delete it or change its matchers.

For a clean “everything else goes to Slack” path, point the default passthrough at your fallback Slack channel.

Create a routing rule

1. Open Alerts → Routing rules and click Create rule.

2. Name the rule and set its priority. Lower numbers win. Give specific rules low numbers (10, 20, 30) and generic ones higher numbers. The default passthrough sits at priority 1,000,000 so unmatched alerts always have somewhere to land.

3. Add matchers. Pick a label key, an operator, and a value. Add as many rows as needed; all matchers combine with AND.

4. Choose how alerts group. Leave Alert grouping on Static and set group-by keys: empty to notify once per alert rule, or a real label key (start with service) to correlate matching alerts into one group (severity isn’t allowed here). Or switch to Auto (AI) to let the correlation engine group related alerts for you, with no keys to set.

5. Set the notification timing. Leave the defaults (30s group wait, 5m group interval) for most cases. Tighten them for time-sensitive notifications, or loosen them for digest-style summaries. Set a Repeat interval such as 1h to be reminded while the alert stays open, or leave it at 0 for no reminders.

6. Pick destination channels. Add one or more channels. If you don’t have a KloudMate Incidents channel yet, use the inline + Add KloudMate Incidents channel link in the picker.

7. Optionally enable Auto-RCA. Toggle Auto-RCA on and set the delay (default 5 minutes after group open). See Auto-RCA.

8. Save.

Row actions

The kebab menu on each row offers:

• Edit: opens the rule editor.
• Duplicate: opens the editor pre-filled with the rule’s settings under a “(copy)” name, so you can adjust matchers or priority and save as a new rule.
• Delete: removes the rule. The delete is blocked while open alert groups still route through this rule; resolve or re-route those groups first, then delete. The default passthrough rule can’t be deleted at all.

The Enabled toggle disables a rule without deleting it. Use it to stage a rule before it goes live.

Suggest rules

Admins can open Suggest rules to get up to five AI-suggested rules based on your workspace’s recent alert traffic.

Each suggestion shows:

• A title describing the proposed grouping (for example, “Group by service + env”).
• A short rationale: how much notification noise the rule would have collapsed over the lookback window.
• A preview matches count for that window.
• Accept opens the create-rule form pre-filled with the suggestion’s matchers, group-by keys, and notification timing, under a name derived from what the rule targets. Dismiss drops the card.

Some suggestions are grouping-only: they propose group-by keys with no matchers. Accepting one starts the rule as a catch-all that groups everything by those keys. Add matchers before saving to scope it to a subset of alerts.

Suggestions don’t persist; closing the drawer discards them. Re-run the suggester whenever you want fresh proposals.

Related

• Alert Groups: what routing rules produce.
• Silences: temporarily suppress matching alerts.
• Notification Channels: set up Slack, KloudMate Incidents, email, and more.
• Auto-RCA: automatic investigations on group open.