We're unable to access Azure PostgresQL DB

Question

We're unable to access Azure PostgresQL DB

Dev 40

W've been using Azure PostgresQL flexible server for our application, since few hrs we're facing the issue accesing the DB, this was business critical DB

Insights:

When we try to update any configuration, got the below error

{

"status": "Failed",

"error": {

"code": "InternalServerError",

"message": "An unexpected error occured while processing the request. Tracking ID: '9ec203f7-ce23-4a40-9af8-8cbfd8e4bd5f'"

}

and we see there were no spikes in memory, CPU, and failed connections as well

Can u guys check and let me know possibilities to restore this ?

Manoj Kumar Boyini 14,415 Reputation points Microsoft External Staff Moderator

2026-05-07T07:03:23.2633333+00:00

Hi Dev

I kindly request you to please share the details requested in the private message for further investigation.
Dev 40 Reputation points

2026-05-08T05:07:44.7666667+00:00
Hi Manoj,

Thanks for picking this up. We've shared the requested details over DM.

In parallel, we'd like the following clarified on this thread so there's a written record (for us and for others hitting similar issues):

Root cause

What is the underlying reason for this failure? Our error tracking ID is 9ec203f7-ce23-4a40-9af8-8cbfd8e4bd5f

Compute tier dependency

Is this class of failure tied to a specific compute tier (Burstable / General Purpose / Memory Optimized)? In other words, would running on a higher tier have prevented this, or is it tier-agnostic?

Recovery path during such failures

What is the recommended way to restore the DB when the server is in this state? In our case:

The Backup & Restore tab itself fails when we try to take an on-demand backup.

Configuration updates return InternalServerError.

CPU, memory, and failed-connection metrics all look normal — so this isn't a resource exhaustion case.

Given the above, please advise:

Is point-in-time restore (PITR) still expected to work while the server is in this failed state?

If on-demand backup is failing, is the automated backup chain also affected?

What's the supported recovery procedure here — is restoring to a new server the only option and even with this any data losses expected?

This is a business-critical workload, so a clear written answer on these three points (in addition to the DM troubleshooting) will help us decide on next steps.

Thanks.

Answer accepted by question author

1 additional answer

Your answer

Manoj Kumar Boyini 14,415 Reputation points Microsoft External Staff Moderator

2026-05-07T07:03:23.2633333+00:00

Hi Dev

I kindly request you to please share the details requested in the private message for further investigation.
Dev 40 Reputation points

2026-05-08T05:07:44.7666667+00:00

Hi Manoj,

Thanks for picking this up. We've shared the requested details over DM.

In parallel, we'd like the following clarified on this thread so there's a written record (for us and for others hitting similar issues):

Root cause

What is the underlying reason for this failure? Our error tracking ID is 9ec203f7-ce23-4a40-9af8-8cbfd8e4bd5f

Compute tier dependency

Is this class of failure tied to a specific compute tier (Burstable / General Purpose / Memory Optimized)? In other words, would running on a higher tier have prevented this, or is it tier-agnostic?

Recovery path during such failures

What is the recommended way to restore the DB when the server is in this state? In our case:

The Backup & Restore tab itself fails when we try to take an on-demand backup.

Configuration updates return InternalServerError.

CPU, memory, and failed-connection metrics all look normal — so this isn't a resource exhaustion case.

Given the above, please advise:

Is point-in-time restore (PITR) still expected to work while the server is in this failed state?

If on-demand backup is failing, is the automated backup chain also affected?

What's the supported recovery procedure here — is restoring to a new server the only option and even with this any data losses expected?

This is a business-critical workload, so a clear written answer on these three points (in addition to the DM troubleshooting) will help us decide on next steps.

Thanks.

Answer 1

Hi Dev

Thank you for your detailed questions — please find the clarifications below:

The issue was caused by a temporary unhealthy state of the underlying service components hosting the database. This led to connectivity failures and management operations (such as configuration updates and backup actions) returning errors.

The service has since been recovered, and the server is now in a healthy state.

This type of issue is not tied to a specific compute tier (Burstable, General Purpose, or Memory Optimized) and is considered tier-agnostic.

However, for production workloads, the General Purpose or Memory Optimized tiers are recommended, as they provide better performance consistency, higher availability characteristics, and are more suitable for business‑critical applications compared to Burstable tiers.

In scenarios where the server becomes unreachable or management operations fail:

Point‑in‑Time Restore (PITR) remains the recommended and supported recovery option. PITR creates a new server using existing backups and does not depend on the current health of the source server.

Automated backups are maintained independently of portal actions like on-demand backups. Even if on-demand backup fails due to the server state, the automated backup chain is typically still usable for recovery.

A restore operation always provisions a new server and does not overwrite the existing one.

Data loss: You can restore to a specific point in time within the configured backup retention period, which generally allows recovery without data loss up to the selected restore point.

Recommended approach:

Perform a PITR to restore the database to a new server.
Validate application connectivity and data consistency on the restored server.
Once the issue is resolved and no longer needed, you can safely delete the original server to avoid ongoing charges.

Please let us know if you have any questions or concerns.

Answer 2

Hi Dev

Our PG Team identified that the underlying VM and database containers were in an unhealthy state, which caused the connectivity and operation failures you experienced.

The containers have now been restarted, and the server is back in a Succeeded / healthy state. You should now be able to access the database and perform operations as expected.

As a best practice, if you encounter similar situations in the future where the server becomes unreachable, you can use Point‑in‑Time Restore (PITR) to recover the database to a new server. This process is fully managed and allows you to restore your data without any data loss within the configured backup retention period.

If you need any assistance with restore operations or face any further issues, please feel free to reach out here we’ll be happy to help.

Hope this helps, Please let us know if you have any questions or concerns.

Answer 3

Dev 40

Hi Team,

We're unable to make changes to this server,

After your team intervention we got the server back and working fine, but when we try to do any operation on it, we're getting the below error

Error occurred stopping the server . An unexpected error occured while processing the request. Tracking ID: '7619c6b1-76cb-491a-a26d-f144391961d3'

Manoj Kumar Boyini 14,415 Reputation points Microsoft External Staff Moderator

2026-05-12T14:02:32.3133333+00:00

Hi Dev

Could you please raise a new thread so we can assist you further.
Dev 40 Reputation points

2026-05-14T04:39:19.6433333+00:00

No longer needed, we've deleted the resource after restoring the data

Share via

We're unable to access Azure PostgresQL DB

1 additional answer

Your answer