Alert Not Resolving After Metric Returns to Normal Value

Question

Hi everyone,

I'm having trouble understanding why my alert is not resolving, even though the metric appears to be back within the expected range.

The alert is configured to fire when the metric is_db_alive is less than 1. My understanding is that once the metric returns to 1, the alert should automatically resolve when autoMitigate is enabled. However, that doesn't seem to be happening.

Am I missing something in how alert resolution works, or is there another factor I should be looking into?

Any insights would be greatly appreciated. This is the first time I've encountered this behaviour.

Thanks in advance!

Answer 1

Hello Eric Maes,

Your expectation is generally correct: when a metric alert is configured with Auto-mitigate enabled, Azure Monitor will automatically resolve the alert after the alert condition is no longer met during subsequent evaluations.

From the screenshots, the alert fired when is_db_alive dropped from 1 to 0, which matches the configured condition (Less than 1). The metric chart also shows that the value later returned to 1, indicating that the database became available again.

However, alert resolution is based on the alert rule's evaluation logic rather than only the latest metric value. Azure Monitor evaluates the metric using the configured:

• Aggregation type (Average, Minimum, Maximum, etc.)
• Aggregation granularity (Period)
• Evaluation frequency
• Auto-mitigation setting

For example, if the rule uses Average or Minimum aggregation, the evaluation window may still include earlier datapoints with a value of 0 even after the metric has recovered to 1. In that situation, the alert can remain in the Fired state until the evaluation window no longer contains the unhealthy values.

I recommend reviewing the following settings in the alert rule:

1. Alert Rule → Condition
   • Aggregation type
     • Threshold
       • Evaluation frequency
         • Aggregation granularity (Period)

Alert Rule → Alert Details

• Verify that Automatically resolve alerts remains enabled.

Alert History

  - Check the evaluation history after the metric returned to **1** to confirm how Azure Monitor is evaluating the recovery condition.
  

Also, the Acknowledged status shown in the alert does not affect auto-resolution. It only reflects the user response state and does not prevent the alert from transitioning to Resolved.

Based on the information currently available, the most likely explanation is that the alert evaluation settings are still considering earlier unhealthy datapoints within the evaluation window, causing the alert condition to remain active even though the latest metric values are healthy.

For reference:

• https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-metric-overview
• Troubleshoot Azure Monitor metric alerts

If you can share the alert rule configuration (Aggregation Type, Period, Evaluation Frequency, and Auto-mitigate setting), we can help determine whether the current behavior is expected based on the rule configuration.

Answer 2

A value of 1 should clear this stateful metric alert, but Azure Monitor resolves it only after the condition is false for three consecutive evaluations on the monitored time series. The Acknowledged value in your screenshot is only the user-response state; it does not change the Fired or Resolved condition.

Open the alert rule and confirm Automatically resolve alerts is enabled, corresponding to autoMitigate being true. Reproduce the evaluation in Metrics using the same resource, metric namespace, dimensions, Average aggregation, period, and evaluation frequency. Verify that is_db_alive emitted 1—not missing data—for all three evaluation windows, and check Alert history for rule edits or state changes.

If those evaluations are healthy but the condition remains Fired, export the rule and confirm autoMitigate is still true. Open Microsoft Support with the alert rule resource ID, fired alert ID, UTC timestamps, and metric chart. That would indicate evaluation-state behavior requiring backend investigation.