Alerts sends out timely notifications when your system is having problems. Sometimes there are notifications you know you don't need to see. You can use muting rules to stop being bombarded by messages you don't want.

Once you've spotted the common elements in your unwanted notifications, you can define muting rules that specifically target those elements, while letting other notifications through. Even when a notification is muted, alerts still gathers data on those violations. Muting rules don't interfere with the alerts process and are applied at the point right before a notification is sent.

Manage muting rules

A muting rule condition is the set of individual expressions made up of attributes, operators, and values that define which violations to target for muting.

You can create, enable, disable, and manage muting rules. Go to one.newrelic.com, in the top nav, click Alerts & AI, and then click Muting rules. Enable or disable muting rules at any time.

Rules can have one of the following statuses:

• Active: Muting is enabled and active.
• Scheduled: Muting is enabled but not active yet (there's a future schedule).
• Ended: Muting is enabled, but no longer active (there's no future schedule).
• Inactive: Muting is disabled.

Create a muting rule

To create a muting rule, click + Add a rule in the Muting rules screen. Enter a name and a description for the muting rule, and select the account to which the rule will apply.

Next, build the violation filter. You can use a subset of violation event attributes (specifically accountId, conditionId, conditionName, entity.guid, nrqlEventType, nrqlQuery, policyId, policyName, runbookUrl (as conditionRunbookUrl), tags.<NAME>, and targetName) and sub-condition operators. Values can be compared against one of your violation attributes, such as an alerts policy ID or a condition name.

Schedule a muting rule

If needed, you can schedule your muting rules.

To do this, select a start time and/or end time. Optionally, you can set the muting rule to last an entire day.

You can also choose to select a time zone for the muting rule schedule. The default is the time zone selected in your user preferences.

You can schedule your muting rules to recur daily, weekly, or monthly. A muting rule that's scheduled to repeat weekly includes the option to select the days of the week to recur. If no days are selected, the weekly recurrence will default to repeating on the day of the week that the muting rule is scheduled to start.

You can also specify when you would like recurrence to end by selecting either a specific date or a certain number of occurrences.

Manage muting rules with NerdGraph

In NerdGraph, you can use the following queries and mutations with your muting rules. You can see the schema in more detail in the API Explorer.

• actor.account.alerts.mutingRule: Fetch a muting rule by id.
• actor.account.alerts.mutingRules: Fetch a list of muting rules for an account.
• alertsMutingRuleCreate: Create a muting rule for an account.
• alertsMutingRuleUpdate: Update a muting rule by id and account id.
• alertsMutingRuleDelete: Delete a muting rule by id and account id.

We've given you some sample queries and mutations examples in this document.

A muting rule has the following fields and components:

How muting rules work

Muting rules are applied at the end of the default alert lifecycle in order to suppress, or mute, notifications. They don't disable existing policies or conditions. For example, you can mute notifications during known system disruptions, such as maintenance windows and deployments. System disruption violations will still be identified, even though the notifications for those violations are muted.

A muting rule uses a set of conditions that match against attributes in a violation event. The muting rules tell us how to:

1. Identify individual violations after they're created, but before an incident is opened.
2. Override their default condition to indicate that they should be "muted."

Currently, muting a violation means that the normal alerts incident lifecycle will be maintained, except that an incident that only contains muted violations will not send out any notifications.

Muting rules override specific violations. They don't disable existing policies or conditions. This allows you to mute violations from specific entities that may be covered by a policy or condition that covers a large number of entities. This also keeps you from having to over-mute your monitoring when you are performing maintenance on a subset of your system.

Muting behavior

The following table describes how the alerts incident lifecycle is affected by muted violations:

Muting behavior with workflows

A triggered violation has a 1:1 ratio with an incident so if a violation is muted then the matching incident will be muted as well. Workflows are triggered by issues that can have one or more incidents, therefore there could be a scenario of muted and not muted incidents combined.

Each issue has one of the following muting states:

• Fully muted (FULLY_MUTED): an issue has all of its open incidents muted (Default value).
• Partially muted (PARTIALLY_MUTED): an issue that has at least one open incident that is muted and one open incident that is not muted.
• Not muted (NOT_MUTED): an issue that has no open muted incidents.

For a step-by-step guide on how to setup your workflows, check out an example demo below:

View muted violations and incidents

When viewing an open or closed incident, violations and incidents are marked as Muted. The following sections show some of these muted violations and incidents, and where you can find them.

An incident with a critical violation that's been muted

An incident that has been muted

Violations and incidents are marked as Muted in the State column:

A list of violations, some of which are muted

A list of alert events, some of which are muted

In the list of alert events, the State column shows which events have been muted.

Mute faceted results using tags.

To mute results of faceted queries, use the tags.FACETED_ATTRIBUTE attribute, where FACETED_ATTRIBUTE represents the attributed you've run a NRQL FACET query on. For example: if your NRQL alert condition includes FACET host in its query, you can target that FACET attribute using tags.host.

NRQL condition queries can accept multiple facet attributes. If you want to be able to filter from attributes in your events or metric time series that have been aggregated, you must add those attributes to your NRQL query FACET clause; for example: FACET host, region, cluster.

For an example of using tags., see Create muting rule.

Sub-condition operators

The following are the logical operators available to use to compare attributes when you're constructing muting rules. For examples of these being used, see Examples.

• EQUALS: Where the supplied value equals the violation attribute value.
• NOT_EQUALS: Where the supplied value does not equal the violation attribute value.
• IN: Where the violation attribute value is present in a list of supplied values (up to 500).
• NOT_IN: Where the violation attribute value is not present in a list of supplied values (up to 500).
• CONTAINS: Where the supplied value string is present in the violation attribute value.
• NOT_CONTAINS: Where the supplied value string is not present in the violation attribute value.
• ANY: Caution: A condition with this operator will mute all violations on the account.
• IS_BLANK: Where the violation attribute value is blank. Null, empty string, etc.
• IS_NOT_BLANK: Where the violation attribute value is not blank. Null, empty string, etc.
• STARTS_WITH: Where the violation attribute value begins with the supplied value string.
• NOT_STARTS_WITH: Where the violation attribute value does not begin with the supplied value string.
• ENDS_WITH: Where the violation attribute value ends with the supplied value string.
• NOT_ENDS_WITH: Where the violation attribute value does not end with the supplied value string.

Muting examples

For more information about making requests to NerdGraph, see the NerdGraph documentation, including GraphQL tutorials.

{
      actor {
        account(id: YOUR_ACCOUNT_ID) {
          alerts {
            mutingRules {
              name
              condition {
                operator
                conditions {
                  attribute
                  operator
                  values
                }
              }
            }
          }
        }
      }
    }

mutation {
      alertsMutingRuleCreate(accountId: YOUR_ACCOUNT_ID, rule: {
        name: "host-1 mute rule",
        description: "Mute host-1 violations",
        enabled: true,
        condition: {
          operator: AND,
          conditions: [{
            attribute: "tags.host",
            operator: EQUALS,
            values: ["host-1"]
          }]
        }
      }) {
        id
      }
    }

mutation {
      alertsMutingRuleCreate(accountId: YOUR_ACCOUNT_ID, rule: {
        name: "host-1 and synthetics/mobile mute rule",
        description: "Mute host-1 and synthetics/mobile violations",
        enabled: true,
        condition: {
          operator: OR,
          conditions: [
            {
              attribute: "targetName",
              operator: EQUALS,
              values: ["host-1"]
            },
            {
              attribute: "product",
              operator: IN,
              values: ["SYNTHETICS", "MOBILE"]
            }
          ]
        }
      }) {
        id
      }
    }

mutation {
      alertsMutingRuleUpdate(accountId: YOUR_ACCOUNT_ID, id: MUTING_RULE_ID, rule: {
        name: "updated name",
        enabled: false
      }) {
        name
      }
    }

mutation {
     alertsMutingRuleDelete(accountId: YOUR_ACCOUNT_ID, id: MUTING_RULE_ID) {
        id
      }
    }