PostgreSQL Flexible Server password reset ARM operation stuck at Started/Accepted — how to determine terminal state?

Question

PostgreSQL Flexible Server password reset ARM operation stuck at Started/Accepted — how to determine terminal state?

Stuart McAllister 0

We issued an administrator-password-only PATCH against an Azure Database for PostgreSQL Flexible Server using API version 2024-08-01.

Azure returned HTTP 202. Our client failed to retain the Azure-AsyncOperation / Location polling URL before exiting.

The Azure Activity Log still contains only Started / Accepted for the corresponding Microsoft.DBforPostgreSQL/flexibleServers/write. The server itself is healthy and Ready, but we understand that server readiness is not proof that the asynchronous password-reset operation reached a terminal state.

No subsequent administrator-password reset has been issued.

We no longer possess the password submitted with the original request, and we do not need it recovered.

Our question is: Is there an authoritative Azure API, Resource Graph query, Activity Log query, or other mechanism to determine the terminal state of that specific PostgreSQL Flexible Server write when the original async-operation URL has been lost?

Alternatively, after this amount of time, can a new administrator-password reset safely supersede the earlier accepted operation, or could the original operation still subsequently complete and overwrite the newer password?

We can provide the exact client request ID, ARM correlation ID, event ID, timestamp, subscription/resource information privately to a Microsoft engineer if required.

Tobi Akinfolarin 0 Reputation points

2026-09-14T03:55:17.44+00:00

Not sure if this helps but worth checking.. I'd suggest going to the resource group for your PostgreSQL flex server in the portal, and check under "Settings" then click "Deployment" to search for the record of that async deployment:

"pgsql RG > Settings > Deployments"

I believe if you saw it in your Activity logs it would have created a deployment entry at the resource group level. That entry should indicate success or failure (and should contain the error msg if it failed)

Your answer

Tobi Akinfolarin 0 Reputation points

2026-09-14T03:55:17.44+00:00

Not sure if this helps but worth checking.. I'd suggest going to the resource group for your PostgreSQL flex server in the portal, and check under "Settings" then click "Deployment" to search for the record of that async deployment:

"pgsql RG > Settings > Deployments"

I believe if you saw it in your Activity logs it would have created a deployment entry at the resource group level. That entry should indicate success or failure (and should contain the error msg if it failed)