Azure Automation Runbooks are not stable with Publish/Save

Its jus a matter of the Publish click to publish the workbook not working. It stays in the editor screen and doesn't go back to the Runbook detail screen while a succesful publish does.

Workaround is to add a extra space in the script where it doesn't hurt, Save the Runbook again and click on Publish. Then it works fine.

It could as well be an unsuccesful Save action (previously) why clicking on Publish doesn't work in the first place. It mostly happens when working and testing the Runbook with many saves and re-publishes.

Hello Mavvoorn,

Thank you for reaching out to the Microsoft Q&A forum.

When investigated we see that you’re running into portal-based inconsistencies when editing and publishing PowerShell runbooks—publishes hang, you have to add dummy whitespace, and schedule parameters vanish. While there’s no public “this is a bug” notice for exactly that scenario, here are a few things you can try for a more stable, repeatable workflow:

Switch to scripting your publishes

• Instead of using the Edit → Publish button in the portal, use the Publish-AzAutomationRunbook PowerShell cmdlet or the REST API. CLI/PowerShell calls tend to avoid portal-side caching or UI sync glitches.

Example:

Publish-AzAutomationRunbook `
  -ResourceGroupName "MyRG" `
  -AutomationAccountName "MyAutomationAccount" `
  -Name "MyRunbook"

Adopt an external authoring tool or CI/CD pipeline

• Use the Azure Automation extension for Visual Studio Code (or Azure DevOps/GitHub Actions) to author, test, and push runbooks. That way you’re working from source control and deploying via ARM templates or Az modules.

• This also gives you change history and sidesteps portal UI quirks.

Manage schedule parameters outside the portal

• Parameters you bind at schedule-creation time become “locked” in the portal UI. If you need to update them often, consider:

– Recreating/updating the schedule via PowerShell (Set-AzAutomationSchedule and Register-AzAutomationScheduledRunbook).

– Externalizing dynamic values into Automation Variables or Key Vault references so you don’t have to re-publish or re-bind the schedule each time.

Monitor for throttling or backend issues

• If publishes still hang, run the “CosmosDBThrottling” and “ContainerRestarts” diagnostics under Azure Automation → Troubleshoot to see if your account’s database layer or container infrastructure is under load.

• You can also try in a different region or test with a simpler runbook to isolate any size-or-complexity factors.

Let me know if any further queries - feel free to reach out!

Reference list:

1. Publish-AzAutomationRunbook cmdlet

https://learn.microsoft.com/powershell/module/Az.Automation/Publish-AzAutomationRunbook

2. Troubleshoot runbook issues & diagnostics

https://learn.microsoft.com/azure/automation/troubleshoot/runbooks

3. Manage runbooks via ARM/PowerShell (CI/CD)

https://learn.microsoft.com/azure/automation/manage-runbooks

4. Azure Automation VS Code extension / source control integration

https://learn.microsoft.com/azure/developer/python/tutorial-vscode-azure-automation

5. Schedule binding via PowerShell

https://learn.microsoft.com/powershell/module/Az.Automation/Register-AzAutomationScheduledRunbook

Thank you for your update. I rather stick to the workaround with adding a fake space and save and publish again. And I accept the fact that in the background there are asynchronious jobs that cause this issue.

The problems with the parameters are disturbing and have the same DevOps cause you explained above with pipelining. As an Azure user I don't expect a full structure of administrative task behind me editing saving testing and editing again based on my test results.

When I build a Runbook in Azure I do iterative development until done with many corrections in the Runbook, saves and testing. What I noticed is that when you start using parameters the reliability of the testing and saving goes down tremendeously. Thus, not workable for me.

What you suggest is to build a correct working script first, but that is not how I work. I work AI assisted; explain functional to AI what I want and ask it to assist me setting it up in Azure. In this case, create a Runbook with parameters.

What I finally did is split up into 2 seperate runbook and NOT use parameters anymore. Each Runbook has build in variables with a value and that works fine.