Skip to content

Create a Router

Use routers to define how Notification Center matches and delivers notifications to specific destinations.

Each router contains routing labels, routing rules, and an optional fallback connector.

Understand when to create a router

Create a router when you need to organize notification delivery by key attributes such as:

  • Team: for example, SRE, Security, or DevOps
  • Environment: for example, prod, staging, or dev
  • Service for microservice-level routing or fine-grained separation

Routers centralize and isolate configurations so that each team or environment can manage its own delivery logic.

Understand router components

ComponentDescription
Routing labelsDefine which notifications this router handles.
Routing rulesControl how matched notifications are forwarded to destinations.
Fallback connectorOptional connector used to send notification when no routing rules match.

Understand routing labels matching logic

A router matches a notification when all defined labels are present in the notification request.
Router LabelsNotification LabelsResult
team:teamA, environment:prodteam:teamA, environment:prod✅ Matched
team:teamA, environment:devteam:teamA, environment:prod❌ Not matched
environment:prodteam:teamA, environment:prod ,service:app1✅ Matched
team:teamA, environment:prodteam:teamA, environment:prod ,service:app1✅ Matched
team:teamA, environment:dev , service:app1team:teamA, environment:prod ,service:app1❌ Not matched

GIF showing creation of router

Create a router

Use these steps to create a router that matches notifications and routes them to connectors.

  1. Select Integrations, then Notification Center and Routers. The Routers list displays all existing routers.
  2. Select + New router.
  3. In the Details section, enter a router name and description.
  4. In the Routing labels section, select one or more labels that define which notifications this router should handle.
    • Example:
      • Team:sre
      • Environment:prod
      • Service:frontend
  5. Based on the routing labels configured, you can see the list of matching entities in panel on the right. This helps you check which entities have the routing labels that will match the router.
  6. In Fallback, select a connector to use if no routing rules match. Fallback connectors ensure notifications are still delivered, for example, to a general Slack channel or monitoring queue.
  7. Select Create router to save the configuration.

The new router appears in the list and becomes available for routing rule creation.

Use a fallback connector

Use a fallback connector to handle unmatched notifications.

Fallbacks route messages to a shared channel or monitoring system when no router rules apply.

This prevents lost notifications when conditions change or new services are added.

Example router configuration

FieldExample
NameSRE Production Router
Labelsteam: sre, environment: prod
Fallback connectorSlack – #general-alerts
DescriptionRoutes production alerts for the SRE team to PagerDuty and Slack.

Routing 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

Route Case notifications

Cases are a supported entity type in Notification Center. Case routing helps teams notify the right responders during the incident lifecycle — from activation through resolution.

When a Case lifecycle event occurs, Notification Center generates a notification event that includes labels and metadata from the Case. Routers use these labels to determine whether the event belongs to them. Once a router matches the event, its routing rules evaluate the configured triggers and optional conditions. If a rule matches, Notification Center sends the notification to the configured connectors.

This routing model separates incident management from notification delivery, allowing teams to manage Case workflows independently from how updates are distributed across communication and response tools.

Create a router and routing rule for Case notifications

  1. Select Integrations, then Notification Center.
  2. Open the Routers tab.
  3. Select + New router.
  4. In Name, enter a router name.
  5. (Optional) Add a Description to explain the router's purpose.
  6. In Routing labels, select the labels used to match Cases. Use the same ownership attributes defined across your infrastructure — Environment, Team, and Service — so routing stays consistent with Ownership Tags in Infra Explorer.
  7. (Optional) Configure a Fallback connector to receive notifications when no routing rule matches.
  8. Select Create router.

After creating the router, add a routing rule:

  1. Open the router and select the Cases tab.
  2. In the Routing rules section, select + New rule.
  3. In Name, enter a name that identifies the rule.
  4. In Notification triggers, define which Case lifecycle events generate notifications.
    • By default, Notify for all trigger types is enabled.
    • Disable it to select specific triggers such as Activated, Acknowledged, Resolved, Closed, Priority changed, or Assignee changed.
  5. Toggle Condition to add filtering logic.
    • Define an expression based on Case attributes such as priority, labels, service, or other metadata.
    • The rule triggers only when the condition evaluates to true.
  6. In Destinations, define where the notification is delivered.
    • Select a Connector to choose the integration that sends the notification.
    • Select a Preset to define the message format used for the connector.
  7. (Optional) Select + Add destination to send notifications to additional connectors.
  8. Select Create routing rule or Save changes.

Example Case routing workflow

  1. A Case becomes Activated.
  2. Notification Center matches a router with the label team:sre.
  3. A routing rule configured for the Activated trigger matches.
  4. Notification Center sends notifications to PagerDuty and Slack to alert responders.

Later in the lifecycle:

  1. The Case becomes Resolved.
  2. A routing rule configured for the Resolved trigger matches.
  3. Notification Center sends a notification to a team channel to share the resolution.

This approach ensures responders receive immediate alerts while stakeholders receive updates as the incident progresses.

Next steps