Defining Routing Rules

Routers allow you to control how notifications are delivered once a notification matches the router’s labels. Within each router, you define routing rules that determine when a notification should be sent and where it should be delivered.

Each router includes two dedicated rule views: Cases and Alerts. Separating these rule types allows teams to manage operational workflows differently depending on the type of event being handled.

This structure helps organizations apply different notification logic for incident management workflows versus alert notifications.

Understand the difference between Cases and Alerts

Although both rule types use the same routing mechanism, they are designed for different operational workflows.

Cases

Cases represent incident management workflows that evolve through multiple lifecycle stages. Routing rules for Cases allow teams to control notifications based on specific incident events, ensuring the right stakeholders are informed as an incident progresses.

Case routing supports multiple lifecycle triggers, such as when a Case is activated, acknowledged, resolved, closed, or when properties such as priority or assignee change.

Use Case routing to notify responders and stakeholders during key stages of an incident lifecycle. Notifications can be delivered to operational systems and communication channels such as on-call platforms, messaging tools, or automation workflows. This helps teams coordinate response, track ownership, and maintain visibility as incidents move from detection to resolution.

Alerts

Alerts represent monitoring events generated by alerting rules or detection systems. Alert routing focuses on operational response, notifying teams when a monitored condition changes.

Alert routing supports two primary trigger events:

• Triggered: When the alert condition is detected
• Resolved: When the alert condition returns to normal

Use alert routing when alerts are sent to a platform that aggregates and correlates alerts into incidents. Routing ensures alert events reach the correct systems for processing and incident creation.

Separating alert routing from Case routing allows teams to handle high-volume monitoring alerts independently from structured incident management workflows.

Understand routing rules

Routing rules define when notifications should trigger and where they should be delivered after a router matches a notification.

Each rule evaluates these main elements:

Element	Why it matters
Notification triggers	Controls which event types generate notifications. This allows teams to avoid unnecessary noise and only notify when meaningful state changes occur.
Conditions	Allows additional filtering beyond router labels. Conditions enable fine-grained routing decisions based on alert metadata, severity, labels, or other attributes.
Destinations	Defines where notifications are delivered and how they are formatted using connectors and presets.
Presets	Defines how the notification message is formatted. Presets control the structure and content of the notification sent to each connector.

Rules are evaluated after the router matches a notification. When a rule matches, the notification is delivered to all configured destinations.

Configure notification triggers

Notification triggers define which lifecycle events generate notifications when a routing rule matches. This helps reduce unnecessary noise and ensures that teams are notified only when meaningful changes occur.

By default, routing rules are configured to notify for all trigger types. You can narrow the selection to send notifications only for specific events.

Trigger types vary depending on the type of rule:

• Case routing rules support multiple lifecycle events, including Activated, Acknowledged, Resolved, Closed, Priority changed, and Assignee changed. These events help teams track how incidents evolve and ensure the right stakeholders receive updates during the incident lifecycle.
• Alert routing rules focus on monitoring events and include Triggered and Resolved states. This allows teams to notify responders when an alert fires and when the condition returns to normal.

Using notification triggers allows teams to tailor notifications to their operational workflow, preventing alert fatigue while ensuring important state changes are communicated.

Router labels and Ownership Tags

Routers match notifications using routing labels. These labels follow the same ownership model used across Coralogix — the three core attributes are environment, service, and team.

This is the same pattern used in Infra Explorer Ownership Tags, where environment, service, and team are resolved automatically from Kubernetes labels, cloud tags, runtime discovery, or manual UI entries.

Using the same ownership attributes for notification routing means:

• Labels already defined on infrastructure carry through to routing decisions
• Teams responsible for a resource are the same teams that receive its notifications
• No separate tagging or mapping is required between infrastructure and Notification Center

This consistency reduces configuration overhead — the ownership model works the same way regardless of where you encounter it in the platform.

Use conditions for additional filtering

Conditions refine when a routing rule applies. Router labels (environment, service, team) determine which router receives a notification, while conditions add filtering logic within the router.

Use conditions when routing decisions depend on more than ownership attributes alone. For example, route notifications based on:

• Priority or severity
• Custom metadata labels
• Specific components within a service
• Alert definition attributes

Conditions are evaluated dynamically when an event occurs. Even if a router matches a notification, the rule sends a notification only when the condition evaluates to true.

Conditions help teams control when notifications trigger while keeping routing configurations organized and scalable.

Define destinations

Destinations determine where notifications are delivered and how they are formatted.

Each destination combines two components:

Component	Purpose
Connector	Defines the delivery channel, such as email, Slack, webhook, or an incident management system
Preset	Defines the message format and structure used when sending the notification

Multiple destinations can be added to a single rule. This allows the same event to notify different systems or teams simultaneously.

For example, a critical production incident may:

• Send an alert to an on-call paging system
• Notify the team Slack channel
• Deliver a formatted message to an email distribution list

This flexibility ensures notifications reach all required stakeholders without duplicating configuration across routers.

Why separating routing by event type helps

Dividing routing rules into Cases and Alerts improves operational clarity and scalability.

This separation helps teams:

• Manage incident lifecycle notifications independently from alert notifications
• Reduce complexity when configuring routing policies
• Apply different notification strategies for monitoring versus incident response
• Maintain cleaner routing configurations as environments scale

By organizing routing rules around event types, Notification Center supports both real-time alerting workflows and structured incident management processes within the same routing framework.

Next steps

• Dynamic templating: Use Tera expressions to build powerful routing conditions
• Routers: Refine router scopes and rule sets for teams, environments, or services
• Connectors and presets: Attach the right destinations and message formats to each rule