Flexible Server stuck: start operation "Accepted" for hours, every stop fails with SeverBusyWithOtherOperation

Question

Flexible Server stuck: start operation "Accepted" for hours, every stop fails with SeverBusyWithOtherOperation

Anca S 0

We have an Azure Database for PostgreSQL Flexible Server (Sweden Central, PostgreSQL 18, Standard_D2ds_v4, General Purpose, no high availability) that we cannot stop anymore.

Timeline (all times UTC, 2026-11-09):

07:03:11 – Our deployment pipeline started the stopped server with az postgres flexible-server start. In the activity log, the operation "Start PostgreSQL server" has been in status "Accepted" ever since and never reported "Succeeded". The CLI call kept waiting until we cancelled it after 25 minutes.
07:08:44 – Activity log shows "Health Event Resolved". Since then the server state is "Ready" and it accepts connections.
Since 07:28:58 – Every stop attempt fails, via CLI (retried every 2 minutes until 09:08) and via the Stop button in the portal (again in the afternoon): (SeverBusyWithOtherOperation) Cannot perform 'Stop' server operation because server '<name>' is busy processing other operation.
The self-help diagnostics in the portal report two platform-initiated downtimes: 09:35:55–09:39:15 and 09:58:47–10:04:45, both "An unexpected problem is preventing restoring access to your Azure Database for PostgreSQL - Flexible server", reason unknown. CPU 10–19 %, memory 14–18 %, no Service Health events for the subscription.
Previous starts of this server took about 2 minutes. We have not changed server parameters recently.

This is a test environment that is normally stopped, so compute keeps being billed while we cannot stop it. Our subscription only has the Basic support plan, so we cannot open a technical support request.

Questions:

Can someone from the product team complete or cancel the stuck start operation so that the server can be stopped again?
Is there anything we can do on our side to clear this state?
How can our pipeline detect this state, for example with a timeout on the start operation, without leaving the server in a busy state?

Thanks a lot!

Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-09T14:49:24.8433333+00:00
Your server is stuck in a long-running control-plane operation, so every new stop request is being rejected with SeverBusyWithOtherOperation while the previous start operation is still active in backend state.

Check Activity Log for the PostgreSQL flexible server and note the exact operation IDs/timestamps for the accepted start and failed stop calls.

Use Azure REST/CLI to query current operation state and wait for terminal status before issuing another stop; avoid repeated stop retries because they keep colliding with the same in-progress operation.

If the operation remains non-terminal for hours, raise a support ticket and share server resource ID, region, operation IDs, and UTC timestamps to request backend operation cleanup.

After backend clears the stuck operation, run a single controlled stop/start validation cycle and monitor metrics/events.

For test environments, add a guard in automation to skip stop/start when operationState is not terminal.

Validation checks:

No new SeverBusyWithOtherOperation responses after backend state is cleared.

Stop/start transitions reach Succeeded/Failed terminal status within normal control-plane window.

References:

Manage Azure Database for PostgreSQL flexible server: https://learn.microsoft.com/azure/postgresql/flexible-server/how-to-manage-server

Azure Activity Log troubleshooting: https://learn.microsoft.com/azure/azure-monitor/essentials/activity-log

Create Azure support request: https://learn.microsoft.com/azure/azure-portal/supportability/how-to-create-azure-support-request

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”
Anca S 0 Reputation points

2026-11-09T15:52:12.47+00:00

Thanks for the answer. The start operation is still only "Accepted" in the Activity Log (since 2026-11-09 07:03:11 UTC), and 48 stop attempts between 07:28 and 11:18 UTC were rejected with SeverBusyWithOtherOperation. We have stopped retrying since then.

Our subscription only has the Basic support plan, so we cannot open a technical support request. Could someone from Microsoft escalate this to the product team or enable a one-time support request, so the stuck start operation can be cleared in the backend?

We can share the resource ID and the correlation ID of the start operation privately. Also, the server has no provisioningState or operationState property (only "state", which is "Ready"), so we could not query the operation state as suggested. Is there a supported way to see the status of a running control-plane operation for a Flexible Server?

Your answer

Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-09T14:49:24.8433333+00:00

Your server is stuck in a long-running control-plane operation, so every new stop request is being rejected with SeverBusyWithOtherOperation while the previous start operation is still active in backend state.

Check Activity Log for the PostgreSQL flexible server and note the exact operation IDs/timestamps for the accepted start and failed stop calls.

Use Azure REST/CLI to query current operation state and wait for terminal status before issuing another stop; avoid repeated stop retries because they keep colliding with the same in-progress operation.

If the operation remains non-terminal for hours, raise a support ticket and share server resource ID, region, operation IDs, and UTC timestamps to request backend operation cleanup.

After backend clears the stuck operation, run a single controlled stop/start validation cycle and monitor metrics/events.

For test environments, add a guard in automation to skip stop/start when operationState is not terminal.

Validation checks:

No new SeverBusyWithOtherOperation responses after backend state is cleared.

Stop/start transitions reach Succeeded/Failed terminal status within normal control-plane window.

References:

Manage Azure Database for PostgreSQL flexible server: https://learn.microsoft.com/azure/postgresql/flexible-server/how-to-manage-server

Azure Activity Log troubleshooting: https://learn.microsoft.com/azure/azure-monitor/essentials/activity-log

Create Azure support request: https://learn.microsoft.com/azure/azure-portal/supportability/how-to-create-azure-support-request

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”
Anca S 0 Reputation points

2026-11-09T15:52:12.47+00:00

Thanks for the answer. The start operation is still only "Accepted" in the Activity Log (since 2026-11-09 07:03:11 UTC), and 48 stop attempts between 07:28 and 11:18 UTC were rejected with SeverBusyWithOtherOperation. We have stopped retrying since then.

Our subscription only has the Basic support plan, so we cannot open a technical support request. Could someone from Microsoft escalate this to the product team or enable a one-time support request, so the stuck start operation can be cleared in the backend?

We can share the resource ID and the correlation ID of the start operation privately. Also, the server has no provisioningState or operationState property (only "state", which is "Ready"), so we could not query the operation state as suggested. Is there a supported way to see the status of a running control-plane operation for a Flexible Server?