Managed Notifications

Causely allows you to configure managed notifications directly in the UI, so teams can control what gets routed, where, and under which conditions, without managing configuration files or infrastructure.

Managed notifications are the recommended approach for most teams. They let you route causal insights based on impact, severity, and context.

Create a Notification Configuration

1. Navigate to Settings → Notifications.
2. Click Create to add a new notification configuration.
3. Choose global or per-cluster processing
4. Enter a name that describes the purpose of the notification (for example, prod-critical-alerts).

The name is used only for identification within Causely and does not affect delivery. Each notification configuration must have a unique name.

Choose Global or Per-Cluster Processing

Select how notifications are processed across your environment. Causely supports two modes:

• Global: One cluster handles notification processing for all clusters. Select the processing cluster once; all notification configurations share it.
• Per-cluster: Each cluster processes its own notifications independently. You will select a processing cluster for each notification configuration. This eliminates the need to filter by cluster when scoping notifications.

Notifications are processed by the Causely Mediator running in the selected cluster.

Select a Notification Type

Choose where you want to receive notifications. Supported destinations include:

• Slack
• Microsoft Teams
• Prometheus Alertmanager
• incident.io
• Splunk On-Call (VictorOps)
• Generic Webhook

The selected type determines both delivery format and required fields in the next step.

Configure Destination-Specific Fields

Depending on the notification type, you may be asked to provide additional details, such as:

• Endpoint URL (for webhooks or alert managers)
• Authentication token (optional, depending on destination)

These fields control how Causely delivers notifications to the selected system.

For the Generic Webhook type, the token is sent verbatim as the HTTP Authorization header. See Generic Webhook for how to format it (for example, Bearer <token>).

For Per-Cluster Processing Choose a Processing Cluster for

Select a cluster to handle notification processing.

Notifications are processed by the Causely Mediator running in the selected cluster.

Add Filters (Optional but Recommended)

Filters allow you to control which causal insights trigger notifications. You can filter by:

• Entity Type: for example Service, HTTP Path, or Node
• Entity ID: the unique identifier of a specific entity
• Entity Name: the display name of an entity. Supports regex matching (see Match entity names with regex below)
• Namespace
• Diagnosis: for example Code Change Regression: CPU Congestion or Database Malfunction
• Severity: Urgent vs. Non-urgent
• Cluster: Not needed when using per-cluster processing, since each configuration is already scoped to a specific cluster.

Filters help reduce noise and ensure notifications are routed only when they matter to the receiving team.

Match entity names with regex

The Entity Name filter supports pattern matching with two operations:

• REGEX: notify when the entity name matches the pattern.
• NOT REGEX: notify when the entity name does not match the pattern.

Matching uses Go's standard regular expression engine (the regexp package, which follows RE2 syntax). RE2 does not support backreferences or lookaround assertions. Patterns are unanchored by default, so a match anywhere in the name counts, use ^ and $ to anchor to the start or end of the name.

Pattern	Matches
checkout	any entity name containing checkout
^checkout	names that start with checkout
-canary$	names that end with -canary
^checkout-service$	exactly checkout-service
(checkout|payment)	names containing checkout or payment
(?i)prod	prod matched case-insensitively (Prod, PROD, …)

For example, use the REGEX operation with ^prod- to notify only on entities whose names start with prod-, or use NOT REGEX with -canary$ to exclude every entity whose name ends in -canary.

Save and Manage Notifications

Once saved, the notification configuration appears in the Notifications list, where you can:

• View active filters
• Edit configuration details
• Disable or delete notifications as needed

Changes take effect immediately and do not require redeploying agents or updating configuration files.

Test the Notification

After saving, you can send a test notification to verify the configuration.

• Optionally apply test-only filters to simulate specific scenarios.
• Review the exact payload that will be sent to the destination.
• Confirm the notification is received and formatted as expected.

Testing helps validate both routing logic and downstream integrations.

When to Use UI-Based Notifications

Managed notifications are best suited for teams that want:

• Centralized, product-managed routing
• Explainable notification logic
• Easy iteration as systems and ownership change

For programmatic or infrastructure-managed setups, notifications can also be configured through the Causely Mediator.