Azure Database for PostgreSQL flexible server stuck in 'starting' state

Question

Our Azure Database for PostgreSQL Flexible Server is stuck in Starting and not accepting connections.

This is the second time this has happened on the same server. The first time looked the same: stuck in Starting, CLI management commands rejected, and it was resolved after platform-side investigation.

Context (same pattern as before):

• Server is stopped every day after office hours and started again every morning via automation
• This has worked fine for weeks
• Nothing changed on our side (config, automation, parameters)
• This morning: automation attempted to start the server, but it has been stuck in Starting for an extended period

What we tried:

• Morning start via automation failed with SeverBusyWithOtherOperation
• CLI output from the automation task: Cannot perform 'Start' server operation because server '<ServerName>' is busy processing other operation.
  • Manual az postgres flexible-server stop also fails with the same SeverBusyWithOtherOperation error
• We have not kept retrying stop/start to avoid further conflicts

Looks like: a stuck backend/control-plane operation, not a config issue.

Request: Please investigate and escalate to a support case if needed.

Happy to share server name, subscription, full CLI output, activity log timestamps, and correlation IDs — let us know what you need.

Answer 1

Hi @Salim Oliviers

Based on the investigation performed by the PG team, this incident was identified as a known issue. The server became stuck in the Starting state due to a service-level hang during the startup workflow, which prevented it from transitioning to a healthy operational state.

The PG team observed that the startup workflow encountered repeated failures while attempting to communicate with the underlying VM agent, causing the server to remain in the Starting state and preventing management operations from completing successfully.

To mitigate the issue, the PG team performed a manual restart, which resolved the hang condition and restored the server to a healthy state.

Based on the findings, there is currently no indication that the issue was caused by configuration changes, automation changes, or actions taken on your side. The issue originated from the platform layer and was mitigated through backend intervention.

As an additional recommendation, since this server is currently running on the Burstable (B2ms) tier and this is the second occurrence of a similar issue, you may consider evaluating a move to the General Purpose tier. General Purpose servers provide dedicated compute resources and may offer a more suitable option for production workloads requiring higher availability and operational consistency.

Answer 2

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

a control-plane issue rather than a database issue. The combination of the server being stuck in Starting, both automation and manual CLI operations returning ServerBusyWithOtherOperation, and the fact that the same server previously recovered only after Microsoft intervention strongly suggests a backend operation is stuck. Since nothing changed in your automation or configuration, this doesn't point to a customer-side problem. I wouldn't keep retrying start or stop operations, since they'll likely continue to fail until the original operation is cleared. At this point, the best option is to open an Azure support request and provide the server name, subscription ID, region, Activity Log entries, correlation IDs, timestamps, and the full CLI output showing ServerBusyWithOtherOperation.

Since this is the second time the same server has entered this state, I'd also ask Microsoft to investigate why the control-plane operation became stuck in the first place rather than just clearing the current operation. Repeated backend locks on the same server aren't expected behavior.

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/