Postgres Flexible Server stuck in "Updating" for 24+ hrs during GP to Burstable scale-down (ServerIsBusy on retry)

Question

I'm scaling down an Azure Database for PostgreSQL Flexible Server from General Purpose (Standard_D2ds_v5) to Burstable (Standard_B2s) in australiaeast. The operation was kicked off via the portal over 24 hours ago and the server has been stuck in state: "Updating" ever since: SKU still shows the original GP size, so the resize never actually applied.

Troubleshooting so far:

• Confirmed state: "Updating" via both az postgres flexible-server show and direct REST call (GET .../flexibleServers/<server-name?api-version=2025-08-01)
• Checked Activity Log over a 7-day window filtered to this resource, only read operations are logged; no write operation appears at all, despite the server clearly having one in progress from its own perspective
• HA is disabled, no read replicas attached, so those aren't a factor
• Retrying the scale-down via CLI (az postgres flexible-server update --sku-name Standard_B2s --tier Burstable) fails immediately with: "(ServerIsBusy) Cannot complete operation while server 'cbw-server' is busy processing another operation. Try again later."

So the server is locked against an operation that isn't visible or traceable anywhere client-side (portal, CLI, REST, Activity Log). This looks like an orphaned/stuck internal operation that needs to be cleared on Microsoft's side.

Has anyone seen this before, or know how to get Microsoft to clear a stuck operation like this? Even on my paid support pla, I'm, getting stuck on step 3/4 of the ticket flow with "Next" greyed out, and pretty much forced to raise the issue here.

Answer 1

Hi @Grant Moran ,
Thank you for your patience while we investigated this issue.

The backend engineering team has confirmed that the stuck provisioning operation has been successfully mitigated. The previously blocked control-plane operation was cleared, and the server is now in a healthy and stable state.

• The server is no longer stuck in the Updating state.
• The orphaned/stuck backend operation has been resolved.
• The server is now operational and reporting a healthy status.
• Management operations can proceed normally.

You may now validate the server status from the Azure Portal or by using az postgres flexible-server show and confirm that the server is functioning as expected.

Answer 2

Hello Grant Moran,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Postgres Flexible Server stuck in "Updating" for 24+ hrs during GP to Burstable scale-down (ServerIsBusy on retry).

This is not a PostgreSQL engine, extension, HA, replica, query, or configuration issue. It is an Azure control-plane/provisioning issue. Azure PostgreSQL Flexible Server supports compute scaling, but the operation is expected to complete through the service-managed scale/restart workflow, not remain in Updating for 24+ hours.

Since PCS is already handling the case, request Azure Database for PostgreSQL Flexible Server backend intervention to clear, complete, or safely roll back the stuck provisioning operation. Do not keep retrying scale, restart, stop/start, or generic ARM update operations, because ServerIsBusy means the server is already locked by another operation and customer-side retries will not clear it. - https://docs.azure.cn/en-us/postgresql/configure-maintain/how-to-restart-server

If the Azure portal support flow is blocked or the Next button is greyed out, create the support request using Azure CLI or Azure Support REST API. - https://learn.microsoft.com/cli/azure/support/in-subscription/tickets and https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request,

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

---

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.