Alert Routing

Route alerts to the right responder(s) based on the tags they carry.

Alert Routing allows you to configure Routing Rules to ensure that alerts are routed to the right responder with the help of event tags attached to them.

Prerequisites

• The User Role associated with the user in the Team must have required permissions to manage Services (ability to manage Routing Rules).

• Ensure you have Tags defined for the Service.

Important: Automation rule CRUD operations have a 5-minute caching delay before changes take effect.

Create Routing Rules

To configure Routing Rules:

1. Navigate to Services -> Service Overview -> select or search for your desired service.

2. On the extreme right, expand the accordion -> In the Automation section, View All.

3. In the Routing Rules section, Add Routing Rules.

4. You can add Routing Rules in three ways:

UI-based Rule Builder (Beginner-friendly)

(a) This box displays all the [event tags](https://support.squadcast.com/docs/event-tagging) defined for this Service, which can be used to define Routing Rules

(b) Select Add new rule

(c) Pick the event tag key and value pair that you are checking for in an incident using the drop-downs

(d) Add Conditions to make your rules more granular

You can create Routing Rules using the following conditions:

Operators	Condition
==	if the payload value is equal to the given value
!=	if the payload value is not equal to the given value
matches/contains	if the payload value matches (or contains) the given value
does not contain	if the payload value does not contain the given value

Note: All these operators are case-sensitive. If you want to make the rules case insensitive, then you have to do it with the regular expression method.

(e) You can route the incident containing the specific event tags to either a User, Squad or an Escalation Policy. Pick the same from the drop-down

(f) Click on Save

Default Service Escalation Policy Override

The Alert Routing Rules will take precedence (override) over the default Escalation Policy for the Service if any of the rules match (evaluate to True) an incoming incident.

Note: The search option under payload is not a free search, we have to search by JSON format, for example, type in payload.annotations to get annotations.

We also have an option for click-to-search, wherein you can click on the keys in the payload to get their required values.

Raw String Method

Note

Once you opt for the Raw String method, you cannot revert to the UI-based Rule Builder method for that rule.

(a) This box displays all the event tags defined for this Service

(b) Select Add new rule

(c) Click on Edit to enable the Raw String method

How to make rules case-insensitive?

1. Click Edit -> Proceed

2. You will see the rule in the regular expression. Now you need to add the command lc (lower_case) before the individual parameters

Here is an example:

re(payload["subscription"]["type"], "Subscription")

The rule says if the payload["subscription"]["type"]contains the string "Subscription" in it then do some actions.

If you want to make the above rule case insensitive, you have to add the command lc before the individual parameters.

The case insensitive rule would look like this,

re(lc(payload["subscription"]["type"]), lc("Subscription")) or

re(lc(payload["subscription"]["type"]), "subscription")

(d) Write your custom Tagging Rule expression and select Route To accordingly

(e) Click on Save

Supported Rules

The rule engine supports expressions with parameters, arithmetic, logical, and string operations.

Basic Expressions

10 > 0, 1+2, 100/3

Parameterized Expressions

tags.severity == "high"

The available parameters are tags

• tags: This parameter contains all the configured tags for a given Service.

Regular Expressions

re(tags.severity, "high.*")

This can be used to check if a particular tag field matches a regular expression.

Example

Below is the set of event tags defined for a Service (as shown in the right panel of the configuration space)

{
	"tags": [
		{
			"severity": "critical"
		},
		{
			"severity": "high"
		},
		{
			"severity": "low"
		}
	]
}

Use-case for Routing Rules

When:

• severity is critical : Route to a Squad

• severity is high : Route to an Escalation Policy

• severity is low : Route to a User

Routing Rules are as follows:

• tags.severity == "critical" route to a squad

• tags.severity == "high" route to an escalation policy

• tags.severity == "low" route to a user

FAQs

1. How do I know if an incident gets routed due to a Routing Rule?

In the Incident’s Activity Timeline the reason for routing, and to which entity it gets routed to, is displayed.

2. What kind of regex can be used to write custom rules?

The rule engine supports expressions with parameters, arithmetic, logical, and string operations. You can also check this out to get an idea of all the expression types accepted in Squadcast. Please do your regex here against Golang flavor as shown in the screenshot below and then, set them up in Squadcast:

3. Can I create OR rules?

Yes, you can. The evaluation between different Routing Rules is OR. Add multiple Routing Rules to enable OR evaluation.

4. While adding a Routing Rule, is the search string in the rule case sensitive?

Yes, that is correct. For example, if your search string is “ALERT” and your payload does not contain “ALERT” but contains “Alert”, this will not be matched. Your search string should be “Alert”.

5. Do Routing Rules have priority?

Yes, you can specify Execution Rule Priority for the rules defined by moving them Up or Down the list of rules.

6. I have configured multiple rules for a particular Service. Can I search through the configured rules to find the rule I am looking for?

Yes, that is doable. You will notice a Search option on the left top of the rules modal. You can type in a word you recall from the rule. Any matching results will yield a narrowed-down set of rules.

Have any questions? Ask the community.