Azure Monitor alert rules that are switched off and no longer watch anything

The risk in an alert rule that is turned off

Alert rules are frequently disabled for a good reason: a noisy threshold during an incident, a maintenance window, a migration. Microsoft’s alert rule management page describes disabling rules for maintenance as a normal operation. The problem is the rules nobody turns back on. They still appear in the portal and in infrastructure code reviews, so the resource looks monitored, while the rule itself evaluates no signal and fires no action group.

The first sign is usually an outage that an alert “should have caught”.

Listing disabled alert rules

Metric alert rules and log search alert rules have separate commands:

az monitor metrics alert list \
  --query "[?enabled==\`false\`].{name:name, rg:resourceGroup}" -o table

az monitor scheduled-query list \
  --query "[?enabled==\`false\`].{name:name, rg:resourceGroup}" -o table

In the portal, Monitor, then Alerts, then Alert rules shows the status column for every rule in scope.

One condition: the rule reports enabled as false

ZopNight reads the alert rule’s enabled property and raises a finding only when it is explicitly false. There is no metric, threshold or time window involved, and the check repeats on every evaluation, so a rule that is switched back on drops out on the next pass.

When the state is unknown, nothing is flagged

If the enabled state could not be read, the rule is not assumed to be off and no finding is raised. ZopNight does not try to judge whether an enabled rule is useful, for example one that has never fired: there is no reliable record of that to base a finding on.

Hygiene, not a cost line

ZopNight attaches no saving to this finding. Azure Monitor prices alert rules by the type and number of signals they watch, and states there is no charge for alert rules while they are disabled. Deleting one therefore saves nothing; the value here is coverage: knowing that every rule you see is actually watching something.

Deciding whether to re-enable or delete

1. Open the rule and read its condition and action groups; check its history for when it was disabled and by whom in the activity log.
2. If the signal still matters, fix any noisy threshold first, then re-enable it: az monitor metrics alert update --resource-group my-rg --name my-rule --enabled true, or for a log alert az monitor scheduled-query update --resource-group my-rg --name my-rule --disabled false.
3. If the resource is gone or the alert was replaced, delete the rule so it stops implying coverage.
4. If the rule is managed in Terraform or Bicep, make the same change in code so the next deploy does not revert it.