Routing
Route notifications to different teams within the same destination or across different destinations using routers.
Overview
Once you have set up one or more connectors and presets for your notifications, routing allows you to route notifications within the same destination or across different destinations. For example, you can configure different metric alerts to be sent to specific R&D teams based on the triggered application.
Routers
Routers are created using labels and other filters, attached to a specific entity type such as Alerts or Cases. When a notification request contains the labels matching those configured in a router, the notification is routed based on the rules defined in the router.
Routing rules
Once a notification request matches the filters defined within a router, rules defined within the router are applied. Rules set the conditions for sending a notification to a destination, a connector-preset combination. This is useful for routing a notification based on attributes like priority, source, or labels. For example, you might send P3 (warning) Alerts to Slack and P1 (critical) Alerts to PagerDuty.
Routing rules for each router are evaluated simultaneously. Any rule that matches will be triggered, and the notification will be sent to all associated destinations. Rule order does not matter.
Create a router
STEP 1. Navigate to the Routing tab and click + New router.
STEP 2. Configure the router, first by setting the router Name and Description.
Router labels
Define the router labels to be attached to the router. These act as filters; incoming notifications are matched against these labels to determine if this router should process them.
Labels are attached to a specific entity type (e.g., Alerts, Cases) during its creation. For example, when configuring an alert definition, users may attach the following labels:
| Label | Description | Example |
|---|---|---|
| Alerts | ||
| routing.group | Coralogix users are attached to one or more groups, through which they are assigned permissions | backend-prod |
| routing.service | The associated service | productcatalogservice |
| routing.environment | The associated instance | staging, prod |
Fallback
If no routing rule matches a notification request, a fallback rule ensures the notification is still delivered to the destination using the connector of your choice and your default preset.
Create a rule
Click + New rule.
Define the condition
Once you’ve named the rule, configure the condition that must be met for the rule to apply. When Alerts are the entity, conditions can be based on:
Alert severity (e.g., P1, P3)
Entity labels (e.g.,
service_name)Custom tags or other alert metadata
Condition templating examples for routing rules can be found here.
Set destinations
Choose one or more destinations for the notification. Each destination includes:
A connector (e.g., Slack, PagerDuty)
A preset configuration
Save your changes.
Example: Routing by alert priority and entity
Suppose you want to handle Alerts differently based on priority and service label. You create three rules:
Rule for P3 Alerts → send to Slack
Rule for P1 Alerts → send to PagerDuty
Rule for service auth-service → send to Slack
This is the sample triggered alert:
{ "name": "Sample alert", "priority": "P1", "entityLabels": { "service_name": "auth-service" } }
All rules are evaluated:
- Rule 1 (P3): ❌ No match
- Rule 2 (P1): ✅ Match → Notification sent to PagerDuty
- Rule 3 (auth-service): ✅ Match → Notification sent to Slack
Result: The notification is sent to both PagerDuty and Slack.