the Automation Account has been taking significantly longer to start the VM.

Hi @SergiuAdmin

If the delay is happening before the runbook actually starts running (for example, the job stays in Queued or Starting for a long time), then this behavior can still be within the documented Azure Automation service behavior.

SLA for Azure Automation runbook start time is 30 minutes, and that 99.9% of runbooks are expected to start within 30 minutes of the planned start time.

When a runbook runs in the Azure sandbox, Azure Automation assigns a worker to run each job, and those workers are shared by many Automation accounts and you can’t control which worker services your job request, and that jobs using the same sandbox are bound by the resource limitations of the sandbox.

For Python runbooks, Microsoft also notes that importing a Python package may take several minutes, and the currently supported Python runtime in Azure Automation is Python 3.10.

If the runbook is now taking longer mainly at the job startup stage, this points to Azure Automation job start latency in the shared execution environment, rather than a documented issue with the VM start command itself.

A practical way to confirm this is to check the Automation job history and see whether most of the delay is spent in Queued/Starting versus Running.

Can you share a few more details?

• How long does the runbook sit in “Queued” versus “Running”?
• Any diagnostics flags from the DelayedScheduledJobs or AAARMThrottling checks?
• Which region is your Automation account in, and how many concurrent jobs do you have?
• Do you see any failed extensions in the Matillion VM blade?
• Is the VM Windows or Linux/cloud-init?

Thanks,

Suchitra.