# Check an active metric alert before changing repeat-notification behavior

> Why can a continuing metric breach produce no new alert, and what changes if the rule becomes stateless?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-117-check-an-active-metric-alert-before-changing-repeat-notification-behavior/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:29:59+00:00
- Modified: 2026-09-10T00:52:38+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: Business Continuity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Why can a continuing metric breach produce no new alert, and what changes if the rule becomes stateless?

## Potentially affected

Azure Monitor metric alert rules.

## DSE recommendation

Inspect the existing alert's state before disabling automatic resolution to obtain repeat notifications.

## Article

## Source facts

Metric alerts are stateful by default. Once a time series has a fired alert, another alert for that series is not fired while the problem persists. Automatic resolution follows three consecutive evaluations that no longer meet the condition. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-troubleshoot-metric).

Setting autoMitigate to false, or clearing Automatically resolve alerts in the portal, makes a metric rule stateless. This also prevents its fired alerts from resolving; they remain fired for their thirty-day retention period. Microsoft documents notification timing ranges for stateless rules rather than a single exact delivery interval. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-troubleshoot-metric).

## Applicability

Use this distinction for Azure Monitor metric alert rules. Identify the exact metric time series and existing alert before interpreting silence as a rule failure. Keep alert generation separate from the investigation of a failed notification channel.

## DSE recommendation

DSE recommends choosing lifecycle behavior deliberately. Ask whether the response process needs one continuing incident or repeated notifications, then document how responders will handle the resulting records. Do not clear automatic resolution merely to make an alert appear again during troubleshooting. Preserve the previous rule definition and obtain agreement from the receiving team before changing the behavior.

## Verification

In an approved test, sustain a breach and then clear it. Observe the fired record, subsequent evaluations and resolution behavior under the selected configuration. Correlate notifications separately. Keep the time-series identity and rule setting with the observations so a reviewer can distinguish stateful suppression from a delivery problem.

## Official references

[Microsoft Learn: Troubleshoot metric alerts](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-troubleshoot-metric).

## Primary reference

- Name: Troubleshoot Azure Monitor metric alerts - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-troubleshoot-metric
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Check an active metric alert before changing repeat-notification behavior,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-117-check-an-active-metric-alert-before-changing-repeat-notification-behavior/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.
