PostgreSQL Flexible Server stuck on change Compute and Storage tier operation

Question

I started an operation to change the Compute and Storage tier of my Azure Database for PostgreSQL instance around five hours again and the operation has still not completed.

Nothing's showing in the Activity Log or Service Health that seems related and I don't appear to have any options in the Azure Portal to restart the operation.

I'm looking for someone to tell me how to progress - or raise a support ticket for me. I don't have a paid-for Azure technical support package.

Answer 1

Hello Phil N,

Greetings! Thanks for raising this question in the Q&A forum

Compute and storage tier changes on Flexible Server normally complete quickly (typically 2 to 10 minutes with standard scaling, and under 30 seconds if your region and configuration support Near Zero Downtime Scaling), because a scale operation only requires the standby to update and then the primary to briefly restart onto the new SKU. Five hours with nothing in Activity Log or Service Health, and no visible way to cancel from the portal, points to the backend ARM deployment for that operation being stuck rather than the scaling process itself still genuinely running. This is a known failure mode where the portal's scaling blade issues a deployment that never reports back a terminal state, leaving the resource locked in an "updating" state indefinitely.

Steps to try yourself first (no support plan required):

1. Confirm the server's actual state via CLI/REST rather than trusting the portal blade.

az postgres flexible-server show --resource-group <resource-group> --name <server-name> --query "state"

If this returns something other than Updating (e.g., Ready), the change may have already applied on the backend and the portal is just showing stale state, in which case a browser refresh or re-signing into the portal can resolve it.

1. Check the resource group's deployment history, not just the resource's own Activity Log, since the scaling operation runs as a deployment:

az deployment group list --resource-group <resource-group> --query "[?contains(name, 'PatchFlexServer') || contains(name, 'Microsoft.DBforPostgreSQL')]"

Look for a deployment tied to this server with a Running or Failed provisioningState that doesn't match what the portal shows.

1. Retrieve the correlation ID for the stuck operation, so you have it ready regardless of which path you take next:

az monitor activity-log list --resource-group <resource-group> --start-time <5-hours-ago-UTC> --query "[?contains(resourceId, '<server-name>')]"

Do not attempt to stop, restart, or delete the server while it shows as updating. Interrupting a stuck deployment on a Flexible Server can leave it in a worse, harder-to-recover state than simply waiting it out or escalating.

Check the Azure Status page at https://azure.status.microsoft/en-us/status for any active PostgreSQL Flexible Server incidents in your region, since a stuck scaling operation with no portal-side explanation is sometimes tied to a broader, not-yet-published regional issue.

On raising a ticket without a paid support plan:

Community members and moderators can't raise a support ticket on your behalf, that has to come from an account with Owner, Contributor, or Support Request Contributor access on the subscription itself. On a Basic (free) support plan, Azure only allows you to open requests for subscription management, billing, and quota increases, not break-fix technical issues like a stuck resource operation, so a straightforward "my scaling operation is stuck" ticket will be blocked at creation.

If steps 1 to 4 don't clear the state, your realistic options are:

• Upgrade to the Developer support plan (low monthly cost, no long-term commitment) specifically to get access to technical ticket submission with a guaranteed initial response time, then open a ticket referencing the correlation ID from step 3. This is usually the fastest path to a genuinely stuck backend deployment being force-cleared by the PostgreSQL service team.
• If you believe this is a broader platform issue rather than something specific to your server, keep an eye on Service Health advisories in the portal (Service Health > Health advisories), since Microsoft sometimes publishes retroactive advisories for stuck-deployment incidents even when nothing showed at the time you started.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.