> ## Documentation Index > Fetch the complete documentation index at: https://docs-xcor.paloaltonetworks.com/llms.txt > Use this file to discover all available pages before exploring further. # Setting monitor muting rules > Create and manage muting rules that silence monitor, SLO, or time series alerts during maintenance, deployments, or known issues. Use muting rules to mute notifications for an entire monitor, a signal from a monitor, a service level objective (SLO), or any stored time series. You can use this capability when you're fixing a known issue and don't want to keep receiving alerts, during scheduled maintenance windows, or when deploying new services. ## View muting rules Select from the following methods to view a list of muting rules and review which monitors and time series they affect. To display a list of defined muting rules, in the navigation menu select ** Alerting > Muting Rules**. You can take the following actions: * Use the **Search muting rules** box to find a specific rule by name. * Filter the list of rules by choosing a rule status, which can be **Active**, **Scheduled**, or **Expired**. * Point to any muting rule to display additional actions: * ** Copy muting rule:** Available for rules that are **Active**, **Scheduled**, or **Expired**. * ** Expire Muting Rule:** Available for rules that are **Active** or **Scheduled**. * Select any muting rule in the list to view its overview. The overview identifies the matched monitor or time series, the start and end times, the creator, and the total monitors and time series affected. When viewing an active muting rule, select a time period to display the alerts the rule muted during that period. For example, show all muted alerts for the past hour to determine whether the muting rule is effectively muting the intended alerts. The **Muted Alerts** section displays the following muting rule statuses. You can change the time period to see which alerts the muting rule affects: * **All alerts** are a complete list of alerts muted during the selected time period. * **Active** alerts are actively triggering, but are currently muted by the muting rule. * **Resolved** alerts were previously triggered and muted by the muting rule, but are no longer triggering. Click the name of the alert to display the [Monitor actions](/investigate/alerts/monitors/monitor-actions) page for the muted monitor. To fetch the defined muting rules with [Chronoctl](/tooling/chronoctl), use this command: ```shell theme={null} chronoctl muting-rules list ``` This command returns a list of YAML documents with the following data structure for each muting rule: ```yaml Chronoctl example icon="square-terminal" theme={null} api_version: v1/config kind: MutingRule spec: slug: my-rule name: My Rule label_matchers: - type: EXACT name: environment value: staging starts_at: "2023-12-12T18:54:46.000Z" ends_at: "2023-12-12T19:54:46.000Z" comment: mute staging alerts ``` To view muting rules with the Cortex XCOR API, use these endpoints: * [`ListMutingRules`](/tooling/api-info/definition/operations/ListMutingRules) lists muting rules. * [`ReadMutingRule`](/tooling/api-info/definition/operations/ReadMutingRule) retrieves a muting rule by its slug. Because the Cortex XCOR API requires authentication, include an API token with your `curl` request, as shown in the following example. For more details, see [Create an API token](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} export CHRONOSPHERE_API_TOKEN="TOKEN" export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io" curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \ -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH" ``` Replace the following: * *`TOKEN`*: Your API token. * *`INSTANCE`*: The subdomain name for your organization's Cortex XCOR instance. * *`METHOD`*: The HTTP method to use with the request, such as `GET` or `POST`. * *`ENDPOINT_PATH`*: The specific endpoint you want to access. ### View per-series muting status on a monitor When you open a [monitor](/investigate/alerts/monitors) in Palo Alto Networks Cortex XCOR, the **Series Legend** displays an **Alert status** for each time series in the chart. When an active muting rule's label matchers match a specific series, the legend shows **Muted** for that series. Other series in the same monitor can display different statuses at the same time. For example, if a muting rule matches `environment=staging`, only series with that label indicate **Muted**. Series with `environment=production` continue to indicate their actual alert status, such as **Critical** or **Warning**. **Muted** appears as a link to the alert page when the series has an active alert, or as plain text when the series has no active alert but its labels match a muting rule. Open any monitor to display the **Alert status** column in the **Series Legend**. ## Create a muting rule You can create a muting rule to mute an entire monitor or specific time series. If you have specific downtime window requirements, you can [schedule](/investigate/alerts/monitors/data-model#schedule) muting rules. You can add a muting rule from the navigation menu from the list of defined monitors or directly from the list of muting rules. Adding a muting rule from an existing monitor pre-populates the matching criteria without having to manually enter that information. As you define a muting rule, the **Preview alerts** section shows which alerts match the rule and would be muted. Based on this preview, you can review and adjust the rule before it's active. To create a muting rule: 1. Choose whether to mute an existing rule or create a new one: * To mute an existing rule: 1. In the navigation menu, select ** Alerting > Monitors** and click the monitor you want to mute. 2. If you want to mute specific time series only (and not the entire monitor), choose the time series from the list in the **Series Legend**. 3. On the same line as the monitor's title, click ** Mute**. * To create a new muting rule, in the navigation menu, select ** Alerting > Muting Rules**, and click **Create muting rule**. 2. Define your muting rule: * **Name**: Required, but doesn't need to be unique. When creating a muting rule from a monitor, this field is prepopulated with that monitor's name. * **What alerts should be muted?**: Select **A monitor**, **An SLO**, or **Time series**. Define the **Matcher** operator and the **Key** and **Value** to match. * **When should it start?**: Start muting **Now** or at a specific **Start time**. * **For how long?**: The **Duration** or defined **End time** of the muting rule. Muting rules are based on the time zone of the creator, with working hours defined as 9 AM to 5 PM Monday through Friday. Creating a rule that extends outside these hours displays an informational message in the muting rule interface. Muting rules support regular expressions, which you can use to match key values against. Refer to the section about how to [match on values using regular expressions](/investigate/alerts/muting-rules#match-on-values-using-regular-expressions). 3. Click **Create**. After you create a muting rule in Cortex XCOR, select it from the list of muting rules and click **Show JSON** to view the complete JSON request for your muting rule. You can copy this JSON snippet and use it in a script with the [Cortex XCOR API](/tooling/api-info). ```json theme={null} { "slug": "lifecycle-match-envoy_cluster_name", "name": "Muting Rule", "matchers": [ { "type": "REGEXP_MATCHER_TYPE", "name": "envoy_cluster_name", "value": "cluster_span_rc.*" } ], // ... } ``` To create a muting rule with [Chronoctl](/tooling/chronoctl), generate a YAML configuration file and submit it: ```shell expandable theme={null} chronoctl muting-rules scaffold > rule.yaml ``` Edit `rule.yaml` to define the muting rule. The following example creates a rule that runs for three hours and matches the `instance` label with the value `localhost:3030`: ```yaml expandable Chronoctl example icon="square-terminal" theme={null} api_version: v1/config kind: MutingRule spec: name: infra rule label_matchers: - type: EXACT name: instance value: localhost:3030 starts_at: "2030-09-07T11:49:35Z" ends_at: "2030-09-07T14:49:35Z" comment: Local requests ``` Configure the muting rule in these YAML fields: * Set `spec.starts_at` and `spec.ends_at` to RFC3339 timestamps. YAML configuration files don't accept relative times such as `+1h`. * Set `spec.name` and `spec.comment` to the rule name and description. * Add each label matcher to `spec.label_matchers`. Set `type` to `EXACT` for `=`, `REGEX` for `=~`, `NOT_EXACT` for `!=`, or `NOT_REGEXP` for `!~`. To mute a specific monitor, set `name` in the label matcher to `alertname` and set `value` to the monitor name. If the monitor name isn't unique, set `name` to `__chrono_monitor_slug` and `value` to the monitor slug. Create the muting rule from the completed file: ```shell expandable theme={null} chronoctl muting-rules create -f rule.yaml ``` To complete this action with the Cortex XCOR API, use the [`CreateMutingRule`](/tooling/api-info/definition/operations/CreateMutingRule) endpoint. Because the Cortex XCOR API requires authentication, include an API token with your `curl` request, as shown in the following example. For more details, see [Create an API token](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} export CHRONOSPHERE_API_TOKEN="TOKEN" export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io" curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \ -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH" ``` Replace the following: * *`TOKEN`*: Your API token. * *`INSTANCE`*: The subdomain name for your organization's Cortex XCOR instance. * *`METHOD`*: The HTTP method to use with the request, such as `GET` or `POST`. * *`ENDPOINT_PATH`*: The specific endpoint you want to access. ### Match on values using regular expressions When creating a muting rule, you can use regular expressions to include or exclude values. In Cortex XCOR, select one of these PromQL **Matchers**: * Exact match (`=`) * Match regex (`=~`) Then, define regular expressions for the values you want to match on. In a Chronoctl YAML configuration file, set `type` in the label matcher to `REGEX` to match values with a regular expression. For example, you might want to match a time series with a label named `envoy_cluster_name` and include any values that begin with `cluster_span_rc`. You can use Cortex XCOR or Chronoctl to define a regular expression pattern that matches based on values such as `cluster_span_rc_shared__spanhandler_proxy_r-0`. When defining your muting rule in Cortex XCOR, specify the following criteria: * Select the **match regex** (`=~`) matcher. * Enter `envoy_cluster_name` as the key. * Enter `cluster_span_rc.*` as the value to match on. To create a muting rule with the defined regular expression with [Chronoctl](/tooling/chronoctl), use this label matcher in the rule's YAML configuration: ```yaml expandable theme={null} label_matchers: - type: REGEX name: envoy_cluster_name value: cluster_span_rc.* ``` ## Edit a muting rule Edit a muting rule to change the name of the rule or update the rule's duration. To edit a muting rule: 1. On the **Muting Rules** page, click the muting rule you want to edit. 2. On the **Muting Rules Details** page, click ** Edit**. The **Edit Muting Rule** drawer opens and displays a message stating when the selected muting rule duration ends. 3. Make one or more changes: * To change the rule's name, update the **Name** field. * To change the duration by a relative time period, select **Extend by** or **Shorten by**. Enter a number in the **Time period** field, and then choose **Hours**, **Minutes**, or **Days** from the menu. The new scheduled time appears next to the duration boxes. * To set a specific end time, select **End time**, and then set a [custom time](/navigate/time-ranges#pick-dates-on-the-calendar). 4. Click **Save**. To edit a muting rule with [Chronoctl](/tooling/chronoctl): 1. Save the existing muting rule to a YAML file: ```shell /RULE_SLUG/ theme={null} chronoctl muting-rules read RULE_SLUG -o yaml > rule.yaml ``` Replace *`RULE_SLUG`* with the rule's slug. 2. Remove the server-managed `created_at` and `updated_at` fields from `rule.yaml`. 3. Update `name`, `ends_at`, or `comment`. Keep `slug`, `starts_at`, and `label_matchers` unchanged. 4. Submit the updated configuration: ```shell theme={null} chronoctl muting-rules update -f rule.yaml ``` To complete this action with the Cortex XCOR API, use the [`UpdateMutingRule`](/tooling/api-info/definition/operations/UpdateMutingRule) endpoint. Because the Cortex XCOR API requires authentication, include an API token with your `curl` request, as shown in the following example. For more details, see [Create an API token](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} export CHRONOSPHERE_API_TOKEN="TOKEN" export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io" curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \ -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH" ``` Replace the following: * *`TOKEN`*: Your API token. * *`INSTANCE`*: The subdomain name for your organization's Cortex XCOR instance. * *`METHOD`*: The HTTP method to use with the request, such as `GET` or `POST`. * *`ENDPOINT_PATH`*: The specific endpoint you want to access. ## Stop a muting rule Use Cortex XCOR or Chronoctl to stop a muting rule, which deactivates the rule and changes its status to **Expired**. To stop a muting rule: 1. On the **Muting Rules** page, take one of the following actions: * Hold the pointer over the muting rule you want to expire and click ** Expire Muting Rule**. * Click a muting rule to open the **Muting Rules Details** page, and then click ** Expire Muting Rule**. 2. In the confirmation dialog, click **Confirm (Expire)**. When viewing an expired muting rule, a counter displays the number of muted alerts and affected monitors while the rule was active. To expire a muting rule with [Chronoctl](/tooling/chronoctl), use this command: ```shell /SLUG/ theme={null} chronoctl muting-rules expire-rule --slug SLUG ``` Replace *`SLUG`* with the rule's slug, such as `3021f691-a0bf-4bdd-a4c8-f8468e5b272a`. ## Delete a muting rule Select from the following methods to delete a muting rule. To permanently delete a muting rule with [Chronoctl](/tooling/chronoctl), use this command: ```shell /SLUG/ theme={null} chronoctl muting-rules delete SLUG ``` Replace *`SLUG`* with the rule's slug, such as `3021f691-a0bf-4bdd-a4c8-f8468e5b272a`. To complete this action with the Cortex XCOR API, use the [`DeleteMutingRule`](/tooling/api-info/definition/operations/DeleteMutingRule) endpoint. Because the Cortex XCOR API requires authentication, include an API token with your `curl` request, as shown in the following example. For more details, see [Create an API token](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} export CHRONOSPHERE_API_TOKEN="TOKEN" export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io" curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \ -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH" ``` Replace the following: * *`TOKEN`*: Your API token. * *`INSTANCE`*: The subdomain name for your organization's Cortex XCOR instance. * *`METHOD`*: The HTTP method to use with the request, such as `GET` or `POST`. * *`ENDPOINT_PATH`*: The specific endpoint you want to access. ## Related topics - [Monitor actions](/investigate/alerts/monitors/monitor-actions.md) - [CreateMutingRule](/tooling/api-info/definition/operations/CreateMutingRule.md) - [UpdateMutingRule](/tooling/api-info/definition/operations/UpdateMutingRule.md) - [ReadMutingRule](/tooling/api-info/definition/operations/ReadMutingRule.md) - [ListMutingRules](/tooling/api-info/definition/operations/ListMutingRules.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.