--- title: Muting rules: Suppress notifications source: https://docs.newrelic.com/docs/alerts/get-notified/muting-rules-suppress-notifications --- Alerts sends out timely notifications when your system is having problems. Sometimes you don't want to see some known notifications. You can use **muting rules** to stop being bombarded by messages that don't need your attention. 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 alert events. Muting rules don't interfere with the alerts process and are applied at the point right before a notification is sent. ## Create a muting rule [#create] > #### ⚠️ IMPORTANT > > Before creating muting rules, you'll need to [create policies](https://docs.newrelic.com/docs/alerts/new-relic-alerts/configuring-alert-policies/create-edit-or-find-alert-policy) and [conditions](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-alert-conditions/) that generate [notifications](https://docs.newrelic.com/docs/alerts-applied-intelligence/notifications/intro-notifications/). To create a muting rule, follow these steps: 1. Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Muting rules** on the left navigation pane. 2. Click **+ Add a rule**. 3. Enter a name and a description (optional) for the muting rule, and select the account to which the rule will apply. 4. Build the alert events filter. You can use a subset of [alert event attributes](https://docs.newrelic.com/docs/alerts/create-alert/condition-details/alert-event-attributes/). Choose an attribute, an [operator](#sub-conditions), and a value. These are the attributes: `accountId`, `conditionId`, `conditionName`, `conditionType`, `entity.guid`, `nrqlEventType`, `nrqlQuery`, `policyId`, `policyName`, `product`,`runbookUrl` (as `conditionRunbookUrl`), `tags.`, and `targetName`). Values are compared against one of your alert event attributes, such as an alerts policy ID or a condition name. 5. Click **Add another condition** if you want to include more filters. /\* Go to \*\*\[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts\*\* and click \*\*Muting rules\*\* on the left navigation pane. You can create complex muting rules to target a small or large set of unwanted notifications. \*/ ## Manage muting rules [#manage] A muting rule condition is the set of individual expressions made up of attributes, operators, and values that define which alert events to target for muting. To create, enable, disable, and manage muting rules, follow these steps: 1. Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Muting rules** on the left navigation pane. 2. Enable or disable muting rules at any time from the **Enabled** column. You also can edit each rule by clicking the icon on the row of each rule. 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. /\* Go to \*\*\[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts > Muting rules\*\*: You can create complex muting rules to target a small or large set of unwanted notifications. \*/ ## Notification options for muting rules [#notify] When a muting rule is active, and an alert event is opened, a user will not receive a notification. You can configure the behavior for notifications when a muting rule is inactive with the two settings below: - **Notify**: If there’s an ongoing alert event after the muting rule window ends, you will be notified. This works by closing the existing, muted alert event, and if the threshold is still being violated, a new alert event will open in a non-muted state, triggering a notification. We recommend keeping this default setting. - **Suppress notification**: If there’s an ongoing alert event after the muting rule window ends, you will not be notified. This works by leaving the existing, muted alert event open past the muting rule window end timestamp. ![How to suppress notifications](https://docs.newrelic.com/images/alerts_screenshot-crop_suppress-notifications.webp "How to suppress notifications") Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **+ Add a rule**. ## Schedule a muting rule [#schedule-muting-rule] If needed, you can schedule your muting rules. To do this, select a start time and 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. ![Schedule your muting window]( "Schedule your muting window") Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Muting rules** on the left navigation pane. Check the flexible and powerful options you have for scheduling your muting rules. 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. > #### ⚠️ IMPORTANT > > The **Repeat** day of the week checkboxes override the **Starts** and **Ends** date fields. If you set a start date and also choose a day of the week, your muting rules will be applied on the first of those days after your start date. You can also specify when you would like recurrence to end by selecting either a specific date or a certain number of occurrences. ### View muted alert events and issues [#ui] When viewing an open or closed issue, alert events and issues are marked as `Muted`. You can view muted alert events and issues in the following locations: - **View a muted issue:** Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Issues & Activity** on the left navigation pane. Click on any muted issue to see details about the critical alert events that have been muted. - **View a list of muted alert events:** Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Issues & Activity** on the left navigation pane. Then select the **alert events tab**. Muted alert events and issues are marked with the icon in the **Muted** column. ### Mute faceted results using `tags.` [#facet-muting] 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](https://docs.newrelic.com/docs/query-data/nrql-new-relic-query-language/getting-started/nrql-syntax-clauses-functions#sel-facet) 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](#create). ## Sub-condition operators [#sub-conditions] These are the logical operators you can use to compare attributes when you're adding muting rules. If you're new to muting rules, see these [examples](https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/alert-notifications/muting-rules-suppress-notifications/#examples). > #### 💡 TIP > > All sub-condition operator values are case-sensitive. For example, if you use `policyName STARTS_WITH 'PROD'` a policy name that starts with 'Prod' won't get picked up. - `EQUALS`: Where the supplied value equals the alert event attribute value. - `DOES_NOT_EQUALS`: Where the supplied value doesn't equal the alert event attribute value. - `IN`: Where the alert event attribute value is present in a list of supplied values (up to 500). - `NOT_IN`: Where the alert event attribute value isn't present in a list of supplied values (up to 500). - `CONTAINS`: Where the supplied value string is present in the alert event attribute value. - `DOES_NOT_CONTAINS`: Where the supplied value string isn't present in the alert event attribute value. - `ENDS_WITH`: Where the alert event attribute value ends with the supplied value string. - `NOT_ENDS_WITH`: Where the alert event attribute value doesn't end with the supplied value string. - `STARTS_WITH`: Where the alert event attribute value begins with the supplied value string. - `DOES_NOT_STARTS_WITH`: Where the alert event attribute value doesn't begin with the supplied value string. - `IS_BLANK`: Where the alert event attribute value is blank. Null, empty string, etc. - `IS_NOT_BLANK`: Where the alert event attribute value is not blank. Null, empty string, etc. - `IS_ANY`: A condition with this operator will mute all alert events on the account. ## How muting rules work [#overview] 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 alert events will still be identified, even though the notifications for those alert events are muted. A muting rule uses a set of conditions that match against attributes in an [alert event](https://docs.newrelic.com/docs/alerts/create-alert/condition-details/alert-event-attributes). The muting rules tell us how to: - Identify individual alert events after they're created, but before an issue is opened. - Override their default condition to indicate that they should be muted. Currently, muting an alert event means that the normal alerting event lifecycle is maintained, except that an issue containing only muted alert events will not send any notifications. Muting rules are determined by the first event that triggered a notification within an issue. This means that if the first notification event was muted due to a muted state, the rest of the issue will be muted as well. Muting rules override specific alert events. They don't disable existing policies or conditions. This allows you to mute alert events 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. The following table describes how the alerts event lifecycle is affected by muted alert events: | IF | THEN | | ----------------------------------------------------------------- | ------------------------------------------------------ | | Event: Issue is activated | | | An issue is activated because of an alert event that is not muted | Notifications for this issue will be sent. | | An issue is activated due to an alert event that is muted | Notifications for this issue will not be sent (muted). | ### Muting behavior with workflows [#workflow-behavior] A triggered alert event has a 1:1 ratio with an issue so if an alert event is muted then the matching issue will be muted as well. Workflows are triggered by issues that can have one or more alert events, therefore there could be a scenario of muted and not muted alert events combined. Each issue has one of the following muting states: - **Fully muted (`FULLY_MUTED`)**: an issue has all of its open alert events muted (Default value). - **Partially muted (`PARTIALLY_MUTED`)**: an issue that has at least one open alert event that is muted and one open alert event that is not muted. - **Not muted (`NOT_MUTED`)**: an issue that has no open muted alert events. For a step-by-step guide on how to set up your workflows, check out an example demo below (approx. 2:17 minutes): [Video](https://fast.wistia.net/embed/iframe/3nf3q2supe) ### Muting behavior with NerdGraph [#manage-with-nerdgraph] In [NerdGraph](https://docs.newrelic.com/docs/apis/nerdgraph/get-started/introduction-new-relic-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](https://docs.newrelic.com/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph#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. You can find some sample queries and mutations examples in [this page](#examples). A muting rule has the following fields and components: | Muting rule | Fields and components | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `accountId` | The muting rule's account ID. A muting rule will only affect alert events that occur in a single account. To mute alert events across multiple accounts, you'll need to create a muting rule for each account separately. | | `actionOnMutingRuleWindowEnded` | The expected behavior at the end of the muting rule window. Valid values of `CLOSE_ISSUES_ON_INACTIVE` or `DO_NOTHING`. If `CLOSE_ISSUES_ON_INACTIVE` is selected then any ongoing issues will be closed and will reopen (with notifications) if alert events continue. | | `condition` | The set of individual expressions that define which alert events to target. A muting rule condition includes: - `operator`: The boolean operator `AND` or `OR` that defines how to combine the set of conditions. - `conditions`: The set of individual expressions (sub-conditions) that target attributes within an alert event. These are evaluated together based on the `operator`. You can have a maximum of 20 sub-conditions for a single muting rule. A sub-condition includes: - `attribute`: A single attribute within an alert event. Go here for a list of [Alert event attributes](https://docs.newrelic.com/docs/alerts/create-alert/condition-details/alert-event-attributes). - `operator`: The comparison function used to compare the selected alert event attribute against values in the condition. Go here for a list of [sub-condition operators](#sub-conditions). - `values`: An array of string values to compare against selected alert event attributes. When the muting rules evaluate a condition, if necessary, values will be coerced from strings. You can use a maximum of 500 values when using an operator that supports comparison against multiple values, such as `IN`. | | `createdAt` | The timestamp when the muting rule was created (UTC). | | `createdBy` | The user ID of the person who created the muting rule. | | `description` | This is an optional text field describing the muting rule. It's a useful way to provide more context for your muting rule. This data is only used for management display purposes. | | `enabled` | Enable or disable the muting rule (Boolean). Enable and disable your muting rules manually. | | `id` | The unique identifier for the muting rule. | | `mutingRuleLifecycleEventPublishedAt` | A datetime stamp representing the last time the muting rule window end behavior was applied. | | `name` (Required) | A text field for the user-friendly name of the muting rule. This is used when listing or referencing a rule. We don't require that the name be unique, but it's recommended. | | `schedule` | The time window when the `MutingRule` actively mutes alert events. - `startTime`: The datetime stamp that represents when the muting rule starts. This is in local ISO 8601 format without an offset. Example: `2020-07-08T14:30:00` - `endTime`: The datetime stamp that represents when the muting rule ends. This is in local ISO 8601 format without an offset. Example: `2020-07-15T14:30:00` - `timeZone`: The time zone that applies to the muting rule schedule. Example: `America/Los_Angeles`. See [Wikipedia's list of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `repeat`: The frequency the muting rule schedule repeats. If it does not repeat, use null. Options are `DAILY`, `WEEKLY`, `MONTHLY`. - `endRepeat`: The datetime stamp when the muting rule schedule stops repeating. This is in local ISO 8601 format without an offset. Example: `2020-07-10T15:00:00`. Note: Either `endRepeat` or `repeatCount` should be used to end a muting rule schedule. Both fields should not be provided together. - `repeatCount`: The number of times the muting rule schedule repeats. This includes the original schedule. For example, a `repeatCount` of 2 will recur one time. A `repeatCount` of 3 will recur two times. Note: Either `repeatCount` or `endRepeat` can be used to end a muting rule schedule. Don't provide both fields together. - `weeklyRepeatDays`: The day(s) of the week that a muting rule should repeat when the repeat field is set to `WEEKLY`. Example: `['MONDAY', 'WEDNESDAY']`. | | `updatedAt` | The timestamp when the muting rule was last modified (UTC). | | `updatedBy` | The user ID of the person who last modified the muting rule. | #### Muting examples [#examples] For more information about making requests to NerdGraph, see the [NerdGraph documentation](https://docs.newrelic.com/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph), including [GraphQL tutorials](https://docs.newrelic.com/docs/apis/graphql-api/tutorials). **Fetch muting rules for account** To fetch the list of muting rules (with name and condition) for an account: ````graphql { actor { account(id: YOUR_ACCOUNT_ID) { alerts { mutingRules { name condition { operator conditions { attribute operator values } } } } } } } ``` ```` **Create muting rule** To create a muting rule and return the muting rule's `id` for muting alert events from NRQL conditions where host facet is `host-1`: ````graphql mutation { alertsMutingRuleCreate( accountId: YOUR_ACCOUNT_ID rule: { name: "host-1 mute rule" description: "Mute host-1 incidents" enabled: true condition: { operator: AND conditions: [{ attribute: "tags.host", operator: EQUALS, values: ["host-1"] }] } } ) { id } } ``` ```` **Create muting rule for specific hosts or products** To create a muting rule and return the muting rule's `id` for muting alert events from infrastructure conditions where the target host is `host-1` or the alert event was from synthetic or mobile monitoring: ````graphql mutation { alertsMutingRuleCreate(accountId: YOUR_ACCOUNT_ID, rule: { name: "host-1 and synthetics/mobile mute rule", description: "Mute host-1 and synthetics/mobile incidents", enabled: true, condition: { operator: OR, conditions: [ { attribute: "targetName", operator: EQUALS, values: ["host-1"] }, { attribute: "product", operator: IN, values: ["SYNTHETICS", "MOBILE"] } ] } }) { id } } ``` ```` **Create a muting rule with a recurring schedule** To create a muting rule scheduled to repeat with these criteria: - Weekly on Tuesday and Friday - End on 01/31/2021 - Return the muting rule's `schedule` and `id` ```graphql mutation { alertsMutingRuleCreate( accountId: YOUR_ACCOUNT_ID, rule: { condition: { conditions: { attribute: "conditionName", operator: ANY, values: "This is a condition" }, operator: AND }, enabled: true, name: "Recur Weekly", schedule: { startTime: "2020-12-01T12:00:00", endTime: "2020-12-01T14:00:00", timeZone: "America/Los_Angeles", repeat: WEEKLY, endRepeat: "2021-01-31T12:00:00", weeklyRepeatDays: [TUESDAY, FRIDAY] } } ) { id schedule { endTime startTime timeZone repeat repeatCount endRepeat weeklyRepeatDays nextStartTime nextEndTime } } } ``` **Rename and disable muting rule** To change the name and disable a muting rule and return its new name: ````graphql mutation { alertsMutingRuleUpdate(accountId: YOUR_ACCOUNT_ID, id: MUTING_RULE_ID, rule: { name: "updated name", enabled: false }) { name } } ``` ```` **Delete muting rule** To delete a muting rule: ````graphql mutation { alertsMutingRuleDelete(accountId: YOUR_ACCOUNT_ID, id: MUTING_RULE_ID) { id } } ``` ````