Azure Monitor alert rules sitting disabled and protecting nothing
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1373 |
| Category | governance |
| Severity | low |
| Metric | none — pure configuration read |
| Source | monitor_alert_unused.go |
Where it applies
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
az monitor metrics alert list \ --query "[?enabled==\`false\`].{name:name, rg:resourceGroup, description:description}" -o tableScheduled 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.