Azure Database for PostgreSQL Flexible Server: all metrics (CPU, Active Connections, Database Is Alive) stopped reporting simultaneously across multiple servers

Question

We're seeing multiple Azure Database for PostgreSQL Flexible Server instances where all metrics (CPU percent, Active Connections, Database Is Alive) stopped reporting data at the exact same timestamp, across different servers. In the Metrics Explorer, CPU percent and Active Connections switch to dotted lines (indicating no data), while Database Is Alive drops to a hard 0.

However:

• Resource Health shows all servers as healthy, no issues.
• Service Health shows no active incidents in our region.
• Applications connect successfully with no errors, and the databases are fully functional.

This looks like a metrics/telemetry ingestion gap rather than an actual server issue, but it's triggering false "unavailable" alerts on our side.

Questions:

1. Is there a known issue with the metrics pipeline for PostgreSQL Flexible Server causing simultaneous gaps in reporting?
2. Is there a recommended way to distinguish a telemetry pipeline gap from real unavailability, other than cross-checking Resource Health?We're seeing multiple Azure Database for PostgreSQL Flexible Server instances where all metrics (CPU percent, Active Connections, Database Is Alive) stopped reporting data at the exact same timestamp, across different servers. In the Metrics Explorer, CPU percent and Active Connections switch to dotted lines (indicating no data), while Database Is Alive drops to a hard 0. However:
   • Resource Health shows all servers as healthy, no issues.
   • Service Health shows no active incidents in our region.
   • Applications connect successfully with no errors, and the databases are fully functional.
   This looks like a metrics/telemetry ingestion gap rather than an actual server issue, but it's triggering false "unavailable" alerts on our side. Questions:
   1. Is there a known issue with the metrics pipeline for PostgreSQL Flexible Server causing simultaneous gaps in reporting?
   2. Is there a recommended way to distinguish a telemetry pipeline gap from real unavailability, other than cross-checking Resource Health?

Answer 1

Hello @Juan Avalo

Based on the behavior you've described, I agree that this looks much more like a PostgreSQL Flexible Server telemetry/metrics pipeline issue than actual database unavailability.

The strongest indicator is that multiple servers stopped reporting several independent metrics at the same timestamp, while:

• Resource Health reports the servers as healthy.
• Applications continue connecting and executing queries successfully.
• Service Health isn't reporting a corresponding regional incident.
• CPU/connection metrics show missing data rather than actual workload behavior.

There have also been previous confirmed cases where PostgreSQL Flexible Server monitoring components became unhealthy and stopped publishing metrics even though the database itself remained operational. In some cases, Microsoft had to restart or repair the backend monitoring container/component; customers can't normally restart this themselves.

One thing I'd be careful about is interpreting Database Is Alive = 0 as definitive proof that PostgreSQL itself is unavailable. Microsoft documents is_db_alive as an availability metric that normally reports 1 when available and 0 when unavailable, at one-minute intervals. However, there have been recent cases where this metric incorrectly remained at 0 while the database continued serving connections normally because the telemetry collector wasn't functioning correctly.

For troubleshooting, I would first query Azure Monitor directly rather than relying only on the portal visualization. For example:

az monitor metrics list \
  --resource "<PostgreSQL-Flexible-Server-resource-ID>" \
  --metric "cpu_percent,active_connections,is_db_alive" \
  --interval PT1M

Run the same query against two or more affected servers. If the API also shows missing datapoints beginning at exactly the same UTC timestamp, that strengthens the case that this is an upstream metric-emission problem rather than Metrics Explorer itself.

For alerting, I also wouldn't rely exclusively on is_db_alive if false positives are operationally significant. Consider correlating it with an independent availability check, such as an application-level/database connectivity probe. That lets you distinguish:

Database Is Alive = 0 + connection probe fails → probable database/service availability issue.

Database Is Alive = 0/no metrics + connection probe succeeds → probable monitoring/telemetry issue.

Regarding whether there's a currently acknowledged regional incident, I don't see a public Microsoft notice identifying this specific Aug. 21 event from the available information. Service Health is also subscription-specific, so the absence of a public announcement doesn't rule out a backend issue affecting a particular cluster or telemetry component.

Given that multiple servers stopped emitting all metrics simultaneously, I would open an Azure support request and provide:

Server resource IDs, Azure region, subscription ID, exact UTC timestamp when metrics stopped, affected metric names, and screenshots/API output showing the common cutoff.

Ask Microsoft specifically to check the PostgreSQL Flexible Server backend monitoring/metrics collector health. Previous cases with very similar symptoms required backend intervention by the PostgreSQL team.

Sharing these references with you:

Microsoft - Monitor Azure Database for PostgreSQL Flexible Server

Microsoft Q&A - PostgreSQL Flexible Server metrics stopped collecting

Microsoft Q&A - Recent Database Is Alive telemetry issue

I would not restart or recreate the PostgreSQL servers at this stage. Since the databases are healthy and several servers experienced the same timestamped failure, server-side changes could introduce unnecessary risk without fixing an upstream telemetry problem.

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.

Answer 2

Update for future poor souls, it seems like it was an issue on Azure Platform side, and got solved by itself after exactly 9 hours.