An Azure managed PostgreSQL database service for app development and deployment.
Hello Michał Grodzki,
Welcome to the Microsoft Q&A and thank you for posting your questions here.
I understand that your Azure Database for PostgreSQL-Flexible server is currently unavailable.
The first step is to triage whether the issue is platform-related or workload-driven. Check Azure Resource Health for any Unavailable (Platform event) or Unknown status, as these often indicate underlying host maintenance or platform incidents. If detected, raise a support case directly from the Resource Health blade, this option is available even without a paid plan and is the proper channel for stalled control-plane operations. In parallel, review Azure Service Health to identify any broader regional service incidents – https://learn.microsoft.com/en-us/azure/service-health/overview.
If no platform event is found, treat the issue as workload saturation. Immediately reduce connection pressure by validating application connection pool settings or enabling PgBouncer on the Flexible Server. To restore stability quickly, scale up to a higher compute tier (e.g., General Purpose or Memory Optimized) and avoid enabling Query Store on Burstable tiers during heavy load. Scaling operations can be completed online – https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-compute-storage.
For diagnosis, use the High Memory Utilization guidance in Azure Monitor – https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-troubleshoot-high-memory-usage to track metrics such as Memory percent, CPU percent, Active connections, and Temp file bytes written. Combine this with in-database queries like:
SELECT pid, state, wait_event_type, wait_event, query_start,
(now() - query_start) AS runtime, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY runtime DESC
LIMIT 20;
These checks help correlate spikes and identify long-running queries or memory-heavy operations. Tune parameters like work_mem, maintenance_work_mem, shared_buffers, and max_connections, following Microsoft’s recommended limits for each tier.
If the server again gets stuck in “Stopping,” re-check Resource Health and open a support case with incident details, activity logs, and metric snapshots to allow Microsoft to investigate control-plane behavior. This process is outlined in the Resource Health documentation – https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview.
For long-term hardening, right-size the server (avoid Burstable for production workloads), enforce connection governance via pooling, enable zone-redundant high availability (HA), and configure Azure Monitor alerts for memory, connection count, and resource state changes. These practices ensure early detection, better performance stability, and faster recovery during both platform and workload events.
I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.
Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.