Azure Database for PostgreSQL: is_db_alive Showing as 0 Despite Server Being Healthy — Metric Issue

Question

Azure Database for PostgreSQL: is_db_alive Showing as 0 Despite Server Being Healthy — Metric Issue

Jarvis 20

Problem description

I am observing that the 'is_db_alive' metric for my Azure Database for PostgreSQL flexible server is consistently showing a value of 0, even though the server is actively serving connections and traffic without any issues. The server's PostgreSQL version is 15.19, and I have not restarted the server recently. I am seeking to understand why this metric remains at 0 despite the server's healthy state.

Environment

Azure Database for PostgreSQL flexible server, PostgreSQL 15.19, region not specified.

What I've already tried

I have not tried anything yet.

Current status

I am looking for guidance on whether this is a known metric emission issue or if there are further steps I should take to diagnose or resolve the discrepancy.

Ganesh Chelluri 195 Reputation points Microsoft External Staff Moderator

2026-09-30T19:58:37.1766667+00:00
Hi @Jarvis ,

Thank you for reporting the discrepancy with the Database Is Alive metric.

The Database Is Alive metric is intended to report whether the database is available, where 1 represents available and 0 represents unavailable. For Azure Database for PostgreSQL Flexible Server, this metric should be evaluated using the Max aggregation. Using Average, Minimum, or an unsuitable time granularity can produce a misleading availability view.

Please complete the following checks:

Open the affected PostgreSQL Flexible Server in the Azure portal.

Go to Monitoring and select Metrics.

Select the Database Is Alive metric.

Set Aggregation to Max and set the time granularity to 5 minutes.

Remove any filters or dimension splits from the chart.

For the same UTC interval, review Succeeded Connections, Failed Connections, Active Connections, CPU percent, Network In, and Network Out.

From an approved client or application host, create a new database connection and run a lightweight query such as SELECT 1. Record the UTC timestamp and result.

Review Resource Health and Activity Log for the same interval to identify any maintenance, restart, scaling, or availability event.

If Max aggregation reports 1 and the connection tests succeed, the database is available and the previous display was caused by the metric-chart configuration.

If the metric remains at 0 while new connections and queries continue to succeed, this should be treated as an availability-metric discrepancy rather than evidence that the database is down. Please share the UTC time range, the aggregation used, and screenshots of Database Is Alive, Succeeded Connections, and Active Connections in private message. Do not include credentials, tokens, full connection strings, or other sensitive information.

We do not recommend restarting or stopping a healthy server solely to correct this monitoring discrepancy.

Verification is complete when Database Is Alive reports 1 with Max aggregation during a period in which direct database connections also succeed.
Jarvis 20 Reputation points

2026-10-01T14:35:11.1533333+00:00

Database Is Alive is still showing 0 after new connection and query was ran from my local machine.

1 answer

Your answer

Jarvis 20 Reputation points

2026-10-01T14:35:11.1533333+00:00

Database Is Alive is still showing 0 after new connection and query was ran from my local machine.

Answer 1

tldr If client connections, query execution, Resource Health, and other monitoring signals all indicate normal operation, investigate the accuracy of the is_db_alive metric itself before concluding that the PostgreSQL server is unavailable.

The Database Is Alive (is_db_alive) metric is intended to indicate database availability, where 1 = available and 0 = unavailable. Azure Database for PostgreSQL Flexible Server emits this metric to Azure Monitor on a regular interval and Microsoft recommends using the MAX aggregation when evaluating availability. (Microsoft Learn)

If your PostgreSQL server is actively accepting connections, serving queries, and other platform metrics continue to update normally, then an is_db_alive value of 0 by itself is not sufficient evidence that the database is unavailable.

A few checks that may help narrow down the cause:

Verify the metric is being viewed with MAX aggregation rather than Average or other aggregations. Microsoft's availability metric guidance specifically references MAX aggregation for determining availability during a given period.
Correlate the timestamp with other metrics such as Succeeded Connections, Active Connections, CPU utilisation, and storage activity. If those metrics show normal activity while is_db_alive remains 0, that suggests a discrepancy between the availability metric and the observed workload behaviour.
Review Resource Health and the Activity Log for any platform events, maintenance activities, or availability incidents that coincide with the affected timeframe.
Query the metric directly through Azure Monitor Metrics or Log Analytics (if exported) to confirm the value is not a portal visualisation issue.
Check whether the behaviour is continuous or intermittent. A continuously reported value of 0 while the database remains fully operational is not the expected behaviour for this metric.

Based on the symptoms described, where the server remains healthy and continues serving traffic, the issue appears more likely to be related to metric collection or reporting rather than an actual PostgreSQL availability problem. The key indicator would be whether connectivity, queries, and other health metrics continue to function normally during the same period.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.