Notification Settings is the central place to control how alerts from Monitors become outbound notifications. It defines where notifications go (targets), what they look like (templates), when and why they are sent (policies), and when they should be suppressed (muting rules).

Notification Settings is organized into four main areas:

• Targets define delivery endpoints such as email, Slack, PagerDuty, AWS SNS, and generic webhooks that a policy or Monitor references. Each target has a stable ID and connection details that can be reused across Monitors and Cribl products.

• Templates define how notifications are formatted for a given target. A template controls message structure and fields (for example, subject, body, or JSON payload) and can include alert context such as monitor name, severity, labels, and links. Policies and Monitors can associate specific templates with targets so each receives an appropriate message format.

• Policies are routing and timing rules. A policy matches alerts based on labels/tags (for example, severity, product, environment, or team), then assigns one or more targets and templates. Policies also control grouping and delay behavior so you can batch related alerts and control reminder frequency.

• Muting Rules define where and when notifications should be suppressed. They match alerts by Monitor and apply a time-boxed window. When a muting rule applies, alerts still evaluate and update in Active Alerts, but outbound notifications are not sent for the muted scope and period.

How Notification Settings Interact with Monitors

​

When an alert instance is created, it carries labels such as severity, product, environment, and any custom tags.

For each state change:

1. Muting rules are evaluated
   Muting rules check the Monitor and time against their conditions. If a matching muting rule is active, notifications for that alert are suppressed for the duration of the mute. The alert instance still appears and updates in the Active Alerts tab, so you retain full history without sending messages.

2. Policies evaluate the alert (unless muted or using direct targets)

   • If the Monitor is set to Route via Notification Policies and the alert is not muted, Cribl evaluates all policies against the alert’s labels. Each matching policy can add targets (and templates) to be notified. This centralizes routing logic and keeps behavior consistent across Monitors.
   • If the Monitor is set to Select Specific Notification Target(s), it bypasses policy evaluation and sends directly to the targets configured on the Monitor itself, following any applicable muting rules.

3. Targets handle delivery, templates shape the message
   For each selected target, Cribl uses that target configuration: endpoint, credentials, integration keys, and so on to deliver the message. If a policy or Monitor has selected a template for that target, the template is used to render the notification payload with alert context.

Typical Workflow

​

• Define shared Targets and Templates once in Notification Settings.

• Create one or more Policies that route alerts by severity, product, environment, or team, and specify grouping/delay behavior.

• Define muting rules for known maintenance windows or noisy scopes, so notifications are suppressed without disabling Monitors.

• Monitor creators set Monitors to Route via Notification Policies, so any alert they generate is matched against shared policies and only sent when not covered by a muting rule. Specific Monitors use Select Specific Notification Target for custom routing.

This separation lets you tune routing, formatting, and suppression in one place without editing every Monitor individually.