Alert Routing

Part of: Alerts — how routing rules decide who hears about which alerts.

Routing rules live on the Alert Routing tab of the Alerts page (/alerts/routing), for users with Manage Alerts. Create one from the page's Add menu.

An alert firing and someone hearing about it are two different things. Alert Routing is where you connect them: a routing rule says which alerts it covers, which notification group hears about them, through which channels, and how loud (or quiet) that audience wants to be. Every enabled rule that matches an alert contributes its audience, so one alert can reach several different groups if more than one rule fits it.

Matching alerts

A rule's Match section decides which alerts it covers, using up to three filters: alert type, minimum severity, and access scope.

The alert type selector

The type picker is organized into categories (today, just Integration Outbox), each expandable to its individual alert types. You can select at three levels:

• All alert types. The rule matches everything, including alert types added in later releases. This is the broadest, and the most future-proof, choice.
• A whole category (checking the category's own checkbox, not the types inside it). This stores the category itself as the selector, not the list of types it currently contains, so an alert type added to that category in a future release is covered automatically. You never have to remember to come back and add it.
• Individual types. Checking specific types within a category covers exactly those types, and only those. A type added to the category later is not included until you edit the rule to add it.

This distinction is the whole point of selecting by category instead of by an enumerated list: a rule built to say "everything in Integration Outbox" keeps meaning that as Tagnet adds more alert types to that category, while a rule built to say "these four specific types" keeps meaning exactly that, on purpose, even as the catalog around it grows.

Why the severity filter disables itself sometimes

The Minimum severity field only becomes usable when your type selection is open-ended, either All alert types or a whole category. That is because open-ended selections can contain types of several different severities, including ones added later whose severity you have not seen yet, so a minimum severity is a meaningful, useful filter on them.

Once you switch to picking individual types, though, each one already has a fixed, known severity, shown right on its chip in the picker. A minimum severity filter layered on top of an exact list could only ever exclude types you deliberately checked, which would be confusing rather than useful, so the field disables itself (and clears, if it had a value) the moment your selection becomes exact picks only.

Why scope-restricted rules skip system-wide alert types

Some alert types are tied to a specific thing with its own access scope, such as one connection profile. Others describe a condition about the system as a whole (a stalled consumer, an aging backlog) and are not tied to any single scoped thing; these are system-wide.

If you set an Access scope on a rule, that rule only matches alerts stamped with that same scope. A system-wide alert is not stamped with any scope at all, so it can never match a scope-restricted rule, no matter what type or severity filters you set. If your type selection includes a system-wide type while the rule is scope-restricted, Tagnet shows a warning right on that type, both while you are building the rule and afterward on the rule's detail page, so you are never left guessing why an alert you expected never arrived.

If every type your rule could ever match turns out to be excluded this way, by severity or by scope, Tagnet refuses to save the rule at all rather than let you publish something that can never fire. That check only applies to individually picked, known types: a category or All alert types selection stays open to types that might qualify in the future, so it never blocks saving, even though it can still show individual warnings.

Reading a rule's match

The rules list keeps the match short: "All alert types", or how many of the catalog's types the rule can actually route (for example "4 of 14 alert types"), followed by the minimum severity and "one scope" when they are set. A type the rule selects but its severity or scope filter rules out is not counted.

A rule's detail page spells it out. The Alert types table in its Match section lists every alert type by category, with the severity it raises at and what it means, and a check mark in the Routed column for each type the rule covers. A type without a check is one the rule leaves out, so you can see what the rule does not do as well as what it does. A category heading notes "whole category, including types added later" when the rule selects the category itself. A type the rule selects but can never route, because it raises below the rule's minimum severity or is system-wide on a scope-restricted rule, shows a warning sign instead of a check, with the reason under its description. For example, a rule for the whole Integration Outbox category at Critical and above flags the category's Warning types.

Rules are additive, and recipients dedupe per person

A rule is a filter, not an exclusive claim. Every enabled rule whose type, severity, and scope filters fit the alert contributes its audience, so if two rules both match the same alert, both audiences hear about it. There is no "first match wins": a routing model that worked that way could silently under-notify people the moment a second rule was added.

When rules combine, Tagnet still notifies each person only once. Recipients from every matching rule are resolved down to concrete, currently-active people (through the notification groups those rules point at) and combined into one set before anything is sent. Someone who is, say, personally listed in one group and also reachable through a role in another group that a second matching rule points at hears about the alert once, not twice.

Sending notifications

The Send to section decides the group, the channels, and whether the audience also hears when the alert clears.

• Notification group. Every rule points at exactly one notification group, the reusable, named list of recipients. Build the group first, then point as many rules at it as make sense; the same group can back several rules.
• Channels. In-app and Email are independent toggles. Turn on either, both, or neither is not allowed: a rule needs at least one active channel, since a rule with no channels would silently do nothing.
• Recovery notice. Off by default. Turning it on tells the same audience when a matched alert resolves, whether that resolution was automatic or manual. It is opt-in per rule because a recovery notice roughly doubles notification volume for that audience, and not every audience wants a "never mind, it's fine now" message on top of the original alert.

The seeded catch-all rule

A fresh Tagnet install ships with one enabled rule already in place: Critical alerts to administrators. It matches every alert type at Critical severity and above, sends to the system Administrators notification group (see Notification Groups), and delivers through both in-app and email. It exists so that critical problems reach someone before anyone has configured anything, on the theory that an alert routing that has to be turned on first is a protection that is not actually on.

Because it is a system rule (shown with an outlined System chip with a lock in the rules list), it cannot be deleted, only disabled, so switching off that baseline protection is a deliberate, visible choice rather than an accidental side effect of cleaning up old rules.

Noise controls

Two settings decide how loud a matched rule's audience hears about an alert, plus one global safety valve that applies no matter what rules are in play.

• Grouping window. How long a brand-new alert waits before its very first notification goes out (2 minutes by default). This exists so a condition that fires and clears again almost immediately never reaches anyone at all: if it would have auto-resolved before you could have acted on it anyway, there is no reason to interrupt you for it.
• Repeat interval. How often the routed audience is re-notified while the alert stays Active and unacknowledged (4 hours by default). Once someone acknowledges the alert, repeats stop entirely, even if the underlying condition is still firing: acknowledging is treated as a claim of ownership, and Tagnet stops paging everyone else about a problem one person has already taken.
• Hourly rate cap and digest. A global ceiling (10 per hour by default) on how many notifications go out per alert type in an hour, not per individual alert. It protects the channel from a flood of distinct alerts of the same kind, such as forty connections failing during the same outage. Once a type crosses its cap for the hour, further alerts of that type stop generating individual notifications and instead collapse into a single digest telling the audience the cap was hit and to check the Alerts inbox for the full list. This cap is global, with no per-rule override, because it protects the recipients' attention as a whole, which no single rule owns on its own.

Grouping window and repeat interval can be overridden on individual rules, for an audience that genuinely needs a faster (or slower) cadence than the rest of the system. Leave either blank to inherit the Alerting policy's defaults, adjustable by an administrator on the Policies page. When an alert matches several rules with different overrides, Tagnet uses the shortest window among them: of two audiences, the more urgent one sets the pace for the alert they share.

Tagnet's background notifier checks for alerts due to send on a short poll interval (30 seconds by default), also set on the Alerting policy. This is an operational tuning knob rather than something you would typically adjust per deployment.