Notification policies control when, where, and how often Cribl Insights sends alert notifications. They act as a routing layer between your Monitors and your delivery targets.

By using policies, you decouple the definition of an alert from its delivery method. This allows you to centralize routing rules based on tags (such as severity, team, or environment) without hard-coding targets into every individual Monitor.

Monitors use notification policies only when their notification mode is set to Route via Notification Policies. If a Monitor uses Select Specific Notification Target, its alerts bypass policies and send directly to the targets configured on the Monitor. Muting rules are evaluated before policy routing: if a muting rule applies, notifications are suppressed even if a policy would otherwise match.

How Policies Work

​

A notification policy is a routing rule. When a Monitor generates an alert, Cribl matches that alert against your ordered list of policies (for Monitors that Route via Notification Policies).

1. Evaluation: The system evaluates the alert labels and tags against the matching conditions of your policies, starting from the top of the list.

2. Matching: If a policy’s conditions match, Cribl associates the policy’s targets with that alert.

3. Flow Control:

   • If the matching policy is marked Final, Cribl routes to that policy’s targets and stops processing subsequent policies.
   • If the matching policy is not Final, Cribl continues evaluating the remaining policies in order. Any additional policies that match can also add targets.

4. Timing: Each matching policy applies its own timing controls to batch notifications and control their frequency (grouping and reminder delays).

If a Monitor uses Direct Target Assignment, Cribl skips policies entirely and sends notifications using the monitor’s configured targets (muting rules still apply).

View and Manage Policies

​

To access your policies, navigate to Insights > Alerts > Notification Settings and select the Notification Policies tab.

The table lists your existing policies and includes:

• Policy Name and Description
• Final: Indicates whether Cribl stops evaluating subsequent policies after this policy matches.
• Conditions: A summary of the label/tag logic used to match alerts.
• Actions: Options to edit, delete, enable/disable, or reorder the policy.

Organize your policies carefully. Cribl evaluates them from top to bottom. Use the drag-and-drop controls in the list view to adjust their precedence.

Create or Edit a Policy

​

When you create or edit a policy, you configure the following:

• Policy name: Enter a name that describes the policy purpose. This name appears in the notification policies list and in any references to the policy.

• Labels: Define which alerts this policy should match. Each label condition tests a label or tag on the alert (for example, severity, env, team):

  • Key: The label or tag name (such as severity, product, env, team).
  • Operator: How to compare the label. Supports:
    • = - equals (for example, severity = CRITICAL)
    • != - does not equal (for example, env != dev)
    • =~ - matches regular expression (for example, team =~ "^sre-.*")
    • !~ - does not match regular expression
  • Value: The value or pattern to match (for example, CRITICAL, prod, sre).
    
    Within a Label Group, the policy matches only when all label conditions in that group are true (logical AND). For example, if you add severity = CRITICAL and env = prod in the same group, the policy applies only to alerts that are both critical and in production.
    
    You can Add Label Group to define multiple, alternative sets of conditions. Each label group is combined with the others using logical OR.
    
    For example, this policy matches alerts that satisfy either Group 1 or Group 2:
    • Group 1: severity = CRITICAL and env = prod
    • Group 2: severity = WARNING and env = staging

• Notification target: Select the notification target that should receive alerts matching this policy. Targets are defined centrally under Notification Settings > Targets. You can add additional rows to send the same alert to more than one target (for example, both PagerDuty and Slack).

• Notification template: Select a template to control how notifications are formatted for the chosen target. If you leave this empty, the default template for that target type is used. Templates are managed under Notification Settings > Templates.

• Final: If enabled, this policy becomes a terminal match:

  • When an alert matches this policy, the system routes to the selected target(s) and stops evaluating any policies below it.
  • If Final is not enabled, the system continues evaluating subsequent policies in order, and those policies can also match and add targets.

  Use Final on specific policies you want to claim alerts, and leave it off for policies that should coexist with others.

• Alert grouping delay (minutes): The number of minutes to wait after the first matching alert before sending the initial notification. During this delay, additional matching alerts can be grouped into the same notification, reducing noise from short spikes or bursts. A small delay is often enough to batch related alerts into a single message instead of sending one notification per individual alert.

After filling out these fields:

1. Save the policy.
2. Ensure the policy is ordered appropriately in the notification policies list, so it evaluates before or after other policies as intended.

Validation and Preview

​

Before you rely on a policy in production, validate its behavior:

• Toggle Preview on to see which current alerts would match the policy and how routing is applied.

• To validate end-to-end delivery, temporarily lower a Monitor threshold or use a non-production tag to trigger a test alert, then confirm:

  • The alert appears in Active Alerts with the expected labels and severity.
  • The correct policy (or policies) match based on your conditions.
  • Notifications arrive at the intended targets with the expected formatting.

If you see too many notifications from a policy, adjust its matching conditions or timing controls. If you see too few, confirm that at least one policy matches the alerts in question and that the policy is enabled.

Best Practices

​

• Order specific before general: Place specific policies with tight tag conditions (for example, severity = CRITICAL AND env = prod) at the top of the list and mark them Final when they should be the only policy that applies. Place broad policies at the bottom.

• Standardize tags: Enforce a consistent tagging strategy at the Monitor level (for example, always tagging env and team). This makes your routing logic deterministic and easier to manage.

• Use policies for most routing: Prefer Route via Notification Policies mode on monitors so routing is controlled centrally. Reserve Select Specific Notification Target for special cases.

• Tune delays: Use Wait to Group Alerts to reduce noise from transient spikes. Adjust Ongoing Alert Interval and Alert Reminder Interval based on your expectations.

• Review regularly: Periodically review which alerts are matching each policy. As your alert volume, teams, and environments evolve, you may need to reorder, refine conditions, or adjust timing to keep notifications effective and actionable.