Azure Automation Account
Does ZopNight manage Azure Automation Account?
Azure Automation accounts bill per job-run minute and per node managed by configuration or update management, past the free monthly allowance. ZopNight discovers each account via Resource Graph, attributes job spend from Cost Management, and flags accounts with no job runs over 30 days (RC-1374, Automation Account Idle).
Rules that fire on Azure Automation Account
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and the idle-account rule (RC-1374); not schedulable. |
Automation accounts run runbooks, configuration management, and update management, billed per job minute and per managed node. They often encode legacy start/stop scripts worth consolidating.
Minutes and managed nodes are what you pay for
An Automation account charges along two lines. Runbook execution bills by job minute: every minute a runbook spends running, across every schedule and webhook trigger, accumulates against the monthly allowance and then onto the bill. Configuration management and update management bill per managed node, a headcount charge that persists for machines enrolled long ago whether or not anyone still reads their compliance reports. The account object itself is just the container; usage is the meter.
Runbooks as a signal, not just a cost
Discovered via Azure Resource Graph, with job spend attributed from Cost Management, and the Automation Account Idle rule flags accounts that ran no jobs over 30 days. ZopNight does not read runbook contents, so finding scheduling scripts is a review worth doing yourself: most Azure estates of any age contain at least one hand-written start/stop runbook, a PowerShell loop over VM names wired to two schedules. Those scripts are exactly the workload ZopNight schedules replace with managed, auditable ones, which makes them consolidation candidates rather than mere line items. The account itself has no stop operation, so it is never scheduled; the idle rule (RC-1374) is the only finding it raises.
Legacy automation that quietly outlives its purpose
The recurring waste shapes: start/stop runbooks still cycling VMs that were deleted or renamed, burning job minutes on failures nobody alerts on; update management still enrolled for decommissioned fleets, paying per-node charges for ghosts; and hourly polling runbooks written before event-driven alternatives existed, whose job minutes dwarf the work they do.
Tracing jobs and schedules in the portal
Azure portal → Automation Accounts, then an account’s Jobs blade, shows every recent execution with duration and outcome. Duration is the billable quantity. The Runbooks and Schedules blades together reveal what is wired to run unattended, which is where forgotten automation hides.