Suppress outbound alert notifications during maintenance windows and other noisy periods.

Muting Rules control when Cribl Insights suppresses outbound notifications for matching alerts. They let you silence notifications during maintenance windows, noisy periods, or for specific alert instances and labels, without disabling Monitors or losing alert history.

When a Muting Rule applies:

• Monitors still evaluate and update alert state.
• Alerts still appear in Active Alerts and keep their status history.
• Notifications are not sent for the muted scope and time window.

This gives you precise control over noise without disabling the Monitor.

How Muting Rules Work ​

Muting Rules are evaluated before Notification routing:

1. A Monitor changes an alert state.
2. If one or more Muting Rules match and are active:
   • The alert is considered muted for Notification purposes.
   • No Notification is sent, even if Notification Policies or direct targets would otherwise apply.
3. If no Muting Rule matches:
   • The alert proceeds to Notification Policies or Direct Target Assignment.
   • Matching policies and targets decide where to send Notifications and how often.

Muting never stops evaluation or hides alerts from the Active Alerts page. It only affects delivery.

Rules are independent of each other. An alert is muted when any active rule matches it, so adding a narrow rule never unmutes an alert that a broader rule already covers.

Muting Rule Scope ​

A Muting Rule matches on a Monitor, plus an optional alert instance and optional tags:

• Monitor is the required anchor. A rule always applies to exactly one Monitor, and Insights cannot evaluate a rule without it.
• Alert Instance ID narrows the mute to one alert instance of that Monitor.
• Tags narrow the mute to alert instances whose labels match.

Within a single rule, the criteria you set are combined with AND. An alert must satisfy every criterion in the rule to be muted by it:

You cannot mute by tags alone. To mute the same tags across several Monitors, create one rule per Monitor.

View and Manage Muting Rules ​

To access Muting Rules:

1. Go to Insights > Alerts.
2. Select the Muting Rules tab.

Use All, Active, Scheduled, or Expired to filter the table. Select Add Muting Rule to create a rule.

The table displays each Muting Rule:

Create or Edit a Muting Rule ​

You can create Muting Rules from Alerts > Muting Rules or from an alert instance in Active Alerts. For the Active Alerts path, see Create a Rule from an Alert Instance.

1. Go to Insights > Alerts.

2. Select the Muting Rules tab.

3. Select Add Muting Rule, or select an existing rule name or Matched Instances count to edit it.

4. Configure the fields:

   Field	Description
   Name	A name that describes why this mute exists.
   Monitor	The Monitor whose alerts you want to mute. Required. If you need to mute multiple Monitors, create a separate rule for each one. When you edit an existing rule, Monitor is locked because instance IDs and tag keys are meaningful only for that Monitor. You can still change Alert Instance ID and Tags to narrow or widen the rule.
   Alert Instance ID	Optional. Limits the mute to one alert instance of the selected Monitor. Leave empty to mute all instances, subject to any Tags you add. The list is populated from that Monitor’s alert history and shows a readable label while storing the instance identifier. Select a Monitor first. When you set both Alert Instance ID and Tags, the rule mutes that instance only while its labels also match the tags. See Muting Rule Scope.
   Tags	Optional. Limits the mute to alert instances whose labels match the tags you add. Select Add Tag, then choose a key and value. Suggestions come from labels on that Monitor’s existing alert instances. Muting Rules support only the = operator. They do not support exclusion tags.
   Duration	How long the mute is active. Relative: enter a duration and unit, such as 2 hours. The mute starts when you save the rule and ends after that duration. Date Range: specify a Start and End date and time. The rule is active only between those times.

5. Review the Matched preview. Monitors is how many Monitors are in scope based on your Monitor selection. Alerts is how many current alerts would be muted if this rule were active now, after applying Alert Instance ID and Tags.

   • If the numbers stay at 0 Monitors 0 Alerts when you expect activity, confirm you selected the correct Monitor and, if you set them, the correct instance and tags.
   • If the numbers are higher than expected, reconsider your scope or duration before saving.

6. Save the rule.

Tags are alert labels, not arbitrary tags you configure on Cribl Stream or Cribl Edge Sources and Destinations. Alert labels come from the metric dimensions and groupings in the Monitor query and from the custom keys you add in the Monitor Metadata section. A Source or Destination tag is available here only when it also reaches the alert as a label.

About Tag Matching ​

Tag matching uses the same model as alert-label routing, described in How Tag Matching Works:

• Different keys use AND. An instance must match every key you specify.
• Multiple values for the same key use OR. An instance matches if its value for that key equals any value you selected.

Create a Rule from an Alert Instance ​

On the Details page in Active Alerts:

• If no Muting Rule already covers this instance, select Add Muting Rule. Insights opens the create form with Name, Monitor, and Alert Instance ID prepopulated (Name uses Mute: followed by the Monitor name).
• If one or more Muting Rules already cover this instance (including a Monitor-wide rule with All instances), the button is Manage Muting Rules. Open it to edit an existing rule or select Create new Muting Rule.

A rule covers the instance when it targets the same Monitor and either has no Alert Instance ID or has this instance’s ID.

Interaction with Notification Policies and Monitors ​

Muting Rules sit in front of Notification routing, affecting the delivery of alerts:

• If a Muting Rule matches:

  • The alert is still created and tracked in Active Alerts.
  • Notification policies and direct targets are not invoked for that alert during the mute window.

• If no Muting Rule matches:

  • Alerts proceed to Notification Policies (for Monitors using Route via Notification Policies) or to the Monitor Select Specific Notification target.

Muting Rules never modify:

• Monitor configuration or thresholds.
• System metrics or evaluation.
• Historical alert data.

Best Practices ​

By using Muting Rules carefully, you can keep notifications actionable and relevant while maintaining full visibility into alert history and system behavior.

• Use time-bounded mutes for maintenance For planned work, create Muting Rules with explicit start and end times that match the maintenance window. Avoid open-ended mutes.

• Prefer narrow scope where possible Start with a single Monitor, then add an Alert Instance ID or Tags rather than muting every instance.

• Use tag-based muting for environments If you routinely need to mute a subset of instances on a Monitor, such as a non-production environment, add tag conditions such as env=staging instead of creating a separate rule per instance.

• Review active mutes regularly Periodically check the Muting Rules tab to ensure no broad or long-lived rules remain active unintentionally.

• Do not use muting instead of tuning If a Monitor is consistently noisy under normal conditions, consider adjusting its thresholds, evaluation windows, or Notification Policies instead of permanently muting it.