Azure PostgreSQL Flexible Server stuck with SeverBusyWithOtherOperation – Unable to Stop/Restart for 4 Days

Joshua Wood 0 Reputation points
2026-10-11T16:53:15.4033333+00:00

Hi,

We have an Azure Database for PostgreSQL Flexible Server that has been unable to complete management operations since 8 October 2026.

The database itself is fully operational and accepting connections, but Azure refuses to stop or restart it, reporting that another operation is already in progress.

This issue has persisted for several days, and we do not have an Azure technical support plan, so we're hoping someone from the Microsoft PostgreSQL engineering team can help investigate.

Environment

Service: Azure Database for PostgreSQL Flexible Server

Region: Sweden Central

SKU: General Purpose

High Availability: Zone Redundant

Server name: psql-argus-uat-sdc-002

Resource group: rg-argus-data-uat-sdc-001

Problem

On 8 October 2026, an automated Start operation was initiated against the server.

The Azure Activity Log shows the Start operation as Accepted, but we cannot find a corresponding Succeeded event.

Since then, attempts to stop or restart the server have failed.

The Azure Activity Log shows the following error (HTTP 400):

{
  "code": "SeverBusyWithOtherOperation",
  "message": "Cannot perform 'Stop' server operation because server 'psql-argus-uat-sdc-002' is busy processing other operation."
}

Interestingly, querying the server through the Azure REST API returns:

{
  "state": "Ready",
  "ha": {
    "mode": "ZoneRedundant",
    "state": "Healthy"
  },
  "provisioning": null
}

The PostgreSQL database remains accessible, and SQL queries execute successfully.

This suggests that the database engine itself is functioning normally, but an Azure management operation may be stuck or holding an internal lock.

Troubleshooting performed

Attempted to stop the server through Azure — failed with SeverBusyWithOtherOperation.

Attempted to restart the server — failed.

Inspected the Azure Activity Log and found that the original Start operation was accepted but has no visible successful completion.

Queried the server using the Azure REST API — server reports Ready, and HA reports Healthy.

Attempted an update to disable HA through the REST API — Azure returned an UpsertServerManagementOperationV2 response, but successful completion has not been confirmed.

Waited several days, but the issue remains unresolved.

Correlation details

Failed Stop operation:

Correlation ID: 39aab544-ba5e-4d13-8920-d9a10403ea76

Timestamp: 2026-10-08T17:07:36Z

HTTP status: 400 BadRequest

Error code: SeverBusyWithOtherOperation

Assistance requested

We have found similar Microsoft Q&A discussions where PostgreSQL Flexible Servers became stuck processing management operations, and Microsoft engineers resolved the issue through backend intervention.

Could someone from the Azure PostgreSQL engineering team please investigate whether an orphaned or stuck management operation is preventing further operations on this server?

Our goal is to restore normal Stop/Start functionality without deleting the server or losing data.

Unfortunately, we cannot raise a standard Azure technical support ticket because our subscription does not have a paid support plan.

We can provide the full Azure resource ID, subscription ID and additional diagnostic information privately if required.

Any assistance or guidance would be greatly appreciated.

Thank you.

Azure Database for PostgreSQL
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Alex Burlachenko 25,530 Reputation points MVP Volunteer Moderator
    2026-10-12T11:21:40.7133333+00:00

    Hi Joshua Wood & thx for join me at Q&A platform,

    this really does look like a stuck management operation rather than a PostgreSQL engine issue. The server reports Ready, HA is Healthy, and SQL connections work normally, but every new management operation gets rejected with SeverBusyWithOtherOperation. After four days, I wouldn't consider that normal operation processing.

    The original Start request being Accepted without a visible Succeeded event is a useful clue, although it doesn't prove that particular operation is still holding the lock. Azure management operations are asynchronous, so the Activity Log alone doesn't always tell the full story. If u still have the original operation-status URL or tracking ID, it's worth checking its final state.

    I'd be careful with the HA change attempt, tho. Disabling zone-redundant HA is another management operation, and if the control plane is already stuck, it could just add another pending operation. I'd avoid further Stop, Restart, or HA configuration changes until Microsoft checks the backend state, especially while the database itself is healthy.

    At this point, the PostgreSQL Flexible Server engineering team needs to inspect the management operation state and determine whether an operation is still running, failed without cleanup, or left an internal lock behind. Include the October 8 Start operation, the failed Stop correlation ID, and the subsequent UpsertServerManagementOperationV2 response so they can investigate the whole sequence. Without a paid technical support plan, getting direct engineering assistance is unfortunately harder. I'd ask a Microsoft Q&A moderator whether they can help route this particular stuck-resource issue to the PostgreSQL service team or identify an available support path. It's not a guaranteed escalation, but there's no safe customer-side command to clear an internal service lock.

    I definitely wouldn't recreate the server or force any HA changes rn. The database is still working, and the goal should be restoring management functionality without putting that at risk.

    rgds,

    Alex

    p.s. if my answer is hepl - pls mark it as an answer

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.