Automation accounts running zero jobs and zero update deployments
What does ZopNight detect here?
ZopNight cross-checks two Azure Monitor series over 30 days (TotalJob for runbook executions and TotalUpdateDeploymentRuns for patch deployments) and flags an Automation account only when both average exactly 0 with full 30-day coverage. Accounts that orchestrate nothing still accrue fixed management charges.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1374 |
| Category | idle |
| Severity | low |
| Metric | none — pure configuration read |
| Source | automation_idle.go |
Where it applies
Two counters, because Automation does two jobs
An Azure Automation account can be busy in two independent ways: ad-hoc or scheduled runbook
jobs, and Update Management deployment runs that patch fleets of VMs. An account with no
runbook activity can still be the thing keeping your servers patched. ZopNight therefore reads
both series, TotalJob and TotalUpdateDeploymentRuns, and requires both to be flat before
calling the account idle. Partial silence is treated as activity, not waste.
A zero that must span the whole month
Both counters must average exactly 0 across a 30-day window, and each series must carry a full 30 days of data before the zero is trusted. A weekly-scheduled runbook shows up well inside that window; a monthly one is the edge case the long window exists for. An account whose monitoring was wired up last week cannot be flagged, because its zeros prove nothing yet.
These are sum-style Azure Monitor metrics, so the decision reads the averaged totals; there is no meaningful peak value to consult on this metric shape.
Reproduce the check with the CLI
az monitor metrics list \ --resource "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Automation/automationAccounts/<name>" \ --metric TotalJob TotalUpdateDeploymentRuns \ --interval P1D --offset 30d --aggregation TotalThirty daily totals of 0 on both metrics reproduces the firing condition.
What suppresses the finding
The rule abstains when either metric series is missing, when either carries less than 30 days of coverage, when either shows any activity at all, or when no positive monthly cost is known for the account. Severity is low: the fixed management charge is real but small, and the finding is about tidiness as much as dollars.
Deciding what to do with a quiet account
Check the runbook list and job history over the last 90 days before deleting. Some accounts exist solely for a disaster-recovery runbook that fires rarely by design, and a DR helper that ran 40 days ago looks idle in a 30-day window. If the account genuinely orchestrates nothing, export any runbook scripts worth keeping and delete it. Detection runs entirely on the Reader and Monitoring Reader built-in roles.