Azure PostgreSQL Flexible Server becomes unavailable intermittently with no clear cause

Question

Hello,

We are reaching out regarding repeated unplanned availability issues with our Azure Database for PostgreSQL – Flexible Server.

On Sunday, December 14, the database instance became Unavailable, and as a result, our application was down for approximately 5 hours. According to the Resource Health logs, the event was reported as Unavailable (Unplanned) – UnknownReason. The service only recovered after we manually changed the compute tier from Burstable to General Purpose.

A similar incident occurred two days earlier (December 11), where the database also became unavailable due to an unplanned event. In that case, the application recovered automatically after approximately one hour.

In both cases, there were no application changes or deployments around the time of the incidents, and the outages appear to have originated at the database or underlying infrastructure level.

We would like to understand:

The root cause of these unplanned outages

Whether this is a known or ongoing issue on the Azure platform

If there is any indication that the issue could be related to our configuration

What preventive measures you recommend to avoid similar incidents in the future

We are currently upgrading the database compute tier and planning to enable high availability, but we would appreciate confirmation on whether this aligns with your recommendations or if additional actions are required.

Thank you in advance for your help. We look forward to your guidance and insights.

Answer 1

Hi Dominique Lachaise,

Thank you for reaching Microsoft Q&A!

Root Cause Analysis: Based on your description, using a burstable SKU (B-series) can lead to performance degradation once CPU credits are depleted, often causing the server to become unresponsive. I recommend checking the CPU and memory usage metrics over the times of the incidents to see if resource exhaustion was a factor.

Here are few steps you can consider:

1. Upgrade Your SKU: Upgrading from the Burstable SKU to a General Purpose or Memory Optimized SKU should provide you with more consistent performance and prevent the outages you’re experiencing. This aligns with your current strategy for upgrading your database compute tier.
2. Enable High Availability: Configuring high availability can help mitigate the impact of unexpected outages. This setup will allow a standby replica of your database to take over in case your primary server goes down.
3. Regular Monitoring: Utilize Azure’s built-in monitoring tools to regularly assess your database’s performance. Setting up alerts for high CPU usage or potential resource exhaustion can help you take action before it leads to downtime.
4. Custom Maintenance Windows: Consider using custom maintenance windows to avoid unexpected downtime during peak application usage times.

After you finish upgrading the SKU and enabling high availability, continuously monitor the performance using Azure Monitor and set alerts for any anomalies.

• If issues persist, consider reaching out to Azure Support for deeper insights specific to your resource and incidents

Reference Documents:

• Manage scheduled maintenance settings for Azure Database for PostgreSQL – Flexible server
• High availability (Reliability) in Azure Database for PostgreSQL
• Handling transient connectivity errors in Azure Database for PostgreSQL.

Thanks!

Kalyani