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 in the left navigation. 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.

The list shows every routing rule in the workspace, sorted by priority (lower wins). The default passthrough rule sits at the bottom. It matches everything that didn’t already match a higher-priority rule, and it can’t be deleted.

Anatomy of a rule

A routing rule has these parts:

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.
Cadence	group_wait (how long to wait after the first alert before sending the first notification) and group_interval (how often to re-notify on an open group).
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	Wire format	Meaning
Equals	equals	Label value matches the string exactly.
Not equals	not_equals	Label value differs from the string (also matches alerts that don’t carry the label at all).
Matches regex	matches_regex	Label value matches the regular expression.
Doesn’t match regex	not_matches_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 the Group-by keys picker is hidden, so you don’t pick grouping keys at all.

In-product, the Auto option reads: “AI and ML automatically correlate related alerts from this rule into a single incident, learning which alerts tend to fire together over time. No grouping keys needed.”

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; that page shows what the grouped incident looks like and how an Auto-correlated group explains itself.

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 two 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.

Cadence

• group_wait: default 30s. The grouping engine waits this long after a group opens before sending the first notification, so closely related alerts have time to fold in.
• group_interval: default 5m. Once a group is open, KloudMate re-notifies at this cadence if new alerts continue to arrive.

The default passthrough rule

Every workspace has a default passthrough rule pinned to the bottom of the list. It matches everything that didn’t match a higher-priority rule. You can edit its destination channels and cadence, 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. Tune cadence. Leave the defaults (30s wait, 5m interval) for most cases. Tighten them for time-sensitive notifications, or loosen them for digest-style summaries.

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. The rule appears in the list at its assigned priority.

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

The list header has a Suggest rules button (visible to admins only). It opens a drawer with 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 cadence, 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.