# Azure Monitor Alert Rule Disabled

> Disabled Azure Monitor alert rules (metric alerts and scheduled query rules whose enabled flag reads "false") are flagged by RC-1373 as dead monitoring configuration. Since a disabled rule monitors no signals, it costs $0, so the finding carries no savings; the remedy is to re-enable the rule or delete it.

Source: https://zop.dev/integrations/azure/recommendations/azure-monitor-alert-rule-disabled
Updated: 2026-08-19

---

## The alert you think you have

A disabled alert rule is worse than no alert rule, because it still shows up in every list.
Someone silenced it during an incident, a migration, or a noisy week, and it never came
back. From then on, the dashboard says "CPU alert: configured" while nothing watches the
signal. The failure mode is a false sense of coverage: the outage arrives, the page never
fires, and the retro discovers the rule was off the whole time. RC-1373 makes that
discovery happen before the outage instead of during the retro.

## An honest zero on the price tag

The original version of this rule claimed a disabled alert rule "still incurs cost" and
gated on cost being positive. The premise is false: Azure Monitor bills per actively
monitored signal or time series, and a disabled rule monitors none, so its charge is
nothing. That also meant the old cost gate could never pass and the rule was structurally
unfireable. The rescoped rule hardcodes $0 for current cost, optimized cost, and savings,
and files the finding under governance. No dollars are invented to make hygiene look like
a saving.

## How disabled state is established

The discoverer reads `properties.enabled` from Azure Resource Graph for both alert-rule
kinds (metric alerts and scheduled query rules) and stamps it into resource metadata.
RC-1373 fires only when that flag is exactly `"false"` and abstains when it is absent. A
prior gate keyed on a `triggered=0` tag that no producer anywhere emitted; the rule could
never fire until it was re-pointed at the authoritative enabled state. Detection needs only
the built-in **Reader** role.

## Enumerate your disabled rules

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

Scheduled query rules have their own list: `az monitor scheduled-query list` with the same
`enabled` filter.

## Two valid outcomes, one invalid one

Re-enable the rule if the condition it watches still matters, ideally after fixing whatever
made it noisy enough to silence. Delete it if the resource or condition is gone, so the next
reviewer does not have to reason about it. The invalid outcome is leaving it disabled
indefinitely: at that point the honest description of your monitoring posture is "no alert",
and the rule row in the portal is just decoration.