PostgreSQL Flexible Server stuck in "Starting" for 10+ hours - ServerBusyWithOtherOperation - backend unlock needed (Spain Central)

Question

Our Azure Database for PostgreSQL Flexible Server has been stuck in the "Starting" state since 2026-07-21 03:00 UTC and every management operation is rejected. We believe this requires backend intervention from the PG team, as in similar cases on this forum.

 

Environment: Flexible Server "srv-postgre-platdig", Spain Central, PostgreSQL 16.14, Standard_D2ds_v5, HA disabled, no replicas.

 

Timeline: - 2026-07-20 ~19:00 UTC: scheduled Stop (Automation Task / Logic App) completed successfully, as every previous day. - 2026-07-21 03:00 UTC: scheduled Start submitted, returned HTTP 202 Accepted. CorrelationId: a9bb81dd-f1d5-418f-bbb9-a58b6985de9f - The Logic App polled the operation for 4 hours, then failed with:   502 BadGateway / OperationTimedOut: "The operation timed out and automatically rolled back. Please retry the operation." (ClientRequestId: 7bfc4215-7d03-4186-aafe-83af445581d7) - The promised rollback never completed: the server never returned to "Stopped" and still shows "Starting". - Manual retries fail immediately (~1s) with: SeverBusyWithOtherOperation: "Cannot perform 'Start' server operation because server 'srv-postgre-platdig' is busy processing other operation." - Portal actions (Stop/Restart) are greyed out. No Succeeded/Failed event appears in the Activity Log after the 202.

 

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

 

Question: Can someone from the PostgreSQL team help clear the stuck control-plane operation and force the server into a stable state (Stopped or Ready)? We are on a Basic support plan; a subscription-management ticket has been filed in parallel [SR number if you have it]. Happy to share further details privately.

Answer 1

hi Eladio Vega Bestard & thx for sharing urs issue here at Q&A portal,

This is a stuck control-plane operation and there’s nothing meaningful left to fix from the customer side. ServerBusyWithOtherOperation immediately after the original Start timed out means the backend workflow still holds the server lock. The fact that Stop and Restart are disabled and no final success or failure appears in Activity Log supports that.

Repeated Start requests, redeploying the Logic App, or changing automation won’t clear it. The PostgreSQL Flexible Server engineering team needs to inspect the internal operation and either complete the rollback or manually release the lock.

The support request should include both correlation IDs, the exact UTC timestamps, server resource ID, region, and the last successful Stop operation. Basic support may not include technical troubleshooting, so they may need to upgrade the support plan or ask subscription support to route it as a service-impacting platform issue.

I’d also disable the scheduled Start/Stop workflow until the server is recovered, so it doesn’t keep submitting conflicting operations.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/