Flexible Server stuck in "Starting" for 2 days - ServerBusyWithOtherOperation, platform-initiated start also hangs

Question

Our Azure Database for PostgreSQL Flexible Server (Spain Central, PostgreSQL 16, General Purpose D2ds_v5, HA disabled, no replicas) has been stuck in the "Starting" state for two days and every management operation is rejected.

 

Timeline: - Day 0, evening: scheduled Stop via Automation Task completed successfully, as it had every previous day. - Day 1, 03:00 UTC: scheduled Start returned HTTP 202 Accepted. The task polled the operation for 4 hours, then failed with 502 BadGateway / OperationTimedOut, stating the operation "timed out and automatically rolled back" and to please retry. - Manual retries that day failed immediately with ServerBusyWithOtherOperation. - Day 1, afternoon: Change Analysis shows the server briefly returned to "Stopped" and then a start initiated by "System" (not by us) moved it back to "Starting". That attempt never completed either. - Day 2, 03:00 UTC: the scheduled Start failed instantly with HTTP 400 and the same ServerBusyWithOtherOperation error.

 

Portal actions are greyed out and no Succeeded/Failed event appears in the Activity Log after the original 202.

 

Ruled out: configuration issues (the identical automation succeeded the 4 previous days in about 4 minutes each), storage exhaustion, and HA/replica interference.

 

Based on similar threads here, this looks like a stuck control-plane operation that only the PostgreSQL backend team can clear. We are on a Basic support plan and cannot open a technical ticket; a subscription-management request has been filed in parallel and we are proceeding with a point-in-time restore to a new server to restore service.

 

Two questions: 1. Can someone from the product team help clear the stuck operation on the original server? 2. Is there a known capacity or control-plane issue in Spain Central over the last 48 hours?

 

I can share the server name, subscription ID and correlation IDs privately.

Answer 1

Hi @Eladio Vega Bestard ,

You've got it right this is a stuck control-plane operation, and only the PostgreSQL backend team can clear it. No customer-side command can force-unlock it. Your PITR plan is correct it builds a new server from backups without touching the original. Use "Latest restore point (Now)", then reset firewall/VNet, DNS, users/roles, parameters and extensions on the new server. For the original: go to the server blade > Resource health and open a support request from there it works even on Basic plan and reaches the backend team fastest. Also stop retrying Start/Restart each attempt re-triggers ServerBusyWithOtherOperation. And avoid posting subscription/correlation IDs publicly.

Hope this helps.

Answer 2

Hello Eladio Vega Bestard,

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

I understand that your Flexible Server stuck in "Starting" for 2 days - ServerBusyWithOtherOperation, platform-initiated start also hangs.

Your Azure Database for PostgreSQL Flexible Server backend operation that did not complete cleanly after the scheduled start operation returned 202 Accepted and later timed out. Since the server is still in Starting and new operations are rejected as ServerBusyWithOtherOperation, do not keep retrying Start, Stop, Restart, Scale, or configuration changes.

Proceed with Point-in-Time Restore to a new Flexible Server, validate the restored server, and cut over the application to the new endpoint as a recovery. PITR creates a new server from the source server backups and does not overwrite the original server. Use Latest restore point (Now) unless you have a specific known-good restore timestamp. - https://learn.microsoft.com/en-us/azure/postgresql/backup-restore/how-to-restore-latest-restore-point, and https://learn.microsoft.com/en-us/azure/postgresql/backup-restore/concepts-backup-restore give more insights.

After the new server is created, restore service by updating the application connection string, validating firewall rules, private endpoint or VNet access, DNS, users, roles, permissions, server parameters, extensions, alerts, and application writes.

For the original server, first check Resource Health for the affected server. If it shows Unavailable, Degraded, Unknown, planned event, or unplanned platform event, open the support request from Resource Health. The next required action is Microsoft backend/Product Group engagement via your Portal or contact priority customer support (PCS). There is no supported customer-side command to force-cancel or unlock a stuck Flexible Server control-plane operation.

Also, there is no confirmed public evidence from the details provided that Spain Central had a broad regional outage. However, use Resource Health and Service Health to validate whether this was a platform, capacity, maintenance, or resource-specific backend issue. - https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview. Use the associated resource links for more reading and steps

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.