Filtering Rules

Filtering rules let you control which notifications reach which channels. Instead of sending everything everywhere, route messages based on priority, tags, or payload content.

How Filtering WorksCopy Anchor Link

Filters are attached to the link between a webhook and a channel. The same channel can have a filter on one webhook and none on another.

When a notification arrives, Alphorn evaluates the filter of each channel linked to the webhook:

• Match - The notification is delivered to that channel
• No match - The notification is skipped for that channel
• No filter - All notifications are delivered (default behavior)

Filters are evaluated once, when the notification arrives. Changing a filter does not affect notifications that were already received.

Setting Up a FilterCopy Anchor Link

1. Create a webhook, or open an existing one and click Edit on the Output Channels card
2. Select a channel, expand it, and click Add filter
3. Pick a field, an operator, and a value
4. Use Add condition to add more conditions to the group, and Add OR group for alternatives
5. Save - Save channels on the webhook page, or Save changes in the edit form

The Clear filter button removes the filter, so the channel receives everything again.

Combining ConditionsCopy Anchor Link

Conditions are organized in groups:

• All conditions within a group must match (AND)
• Any group matching is enough (OR)

For example, "deliver urgent production alerts, or anything tagged security" is two groups:

Fields and OperatorsCopy Anchor Link

PriorityCopy Anchor Link

Priority uses the 1-5 scale (1 = Min, 2 = Low, 3 = Default, 4 = High, 5 = Urgent).

A notification without a priority only matches does not equal.

TagsCopy Anchor Link

Tag matching is case-insensitive.

Title, Message & PayloadCopy Anchor Link

• All comparisons are case-insensitive, including regex.
• A missing title, or a payload path that doesn't exist, is treated as empty text. So does not equal and does not contain match, and the other operators don't.
• Regular expressions that could be very slow (catastrophic backtracking) are rejected at evaluation time and never match. Invalid regexes never match either.
• Values are limited to 1,000 characters.

Payload pathsCopy Anchor Link

Payload conditions take a dot-separated path into the JSON request body. The path is resolved against the whole body, not only a payload key:

Payload values are compared as text - there is no numeric comparison on payload fields. Non-text values are converted first: 42 becomes "42", true becomes "true", null becomes "null", arrays become comma-separated values ("a,b"), and objects become "[object Object]" - so point the path at a single value. To route by severity, map it to the notification priority with a priority template and use a priority filter.

Plain-text notifications have no JSON payload, so payload conditions treat every path as missing (only does not equal and does not contain match).

Testing a FilterCopy Anchor Link

Each filtered channel has a test panel - click Test filter to open it. Enter a sample title, message, priority, tags, and JSON payload, then click Run test to see whether the notification would be delivered and which conditions matched. Invalid JSON in the payload field is treated as an empty object.

Example SetupCopy Anchor Link

Scenario: Critical notifications (priority 4+) go to Email and Telegram so you never miss them. Everything goes to Slack for team visibility.

A notification with priority: 2 goes to Slack only. A notification with priority: 5 goes to Slack, Email, and Telegram. A notification without a priority goes to Slack only.