Intermittent PostgreSQL Flexible Server connection failures (OperationalError) + unexplained App Service InstanceCount fluctuations — no matching Activity Log event

Question

Environment

App Service: Linux, custom Docker container, App Service Plan P2v3, steady-state capacity = 2 instances

Database: Azure Database for PostgreSQL Flexible Server, SKU Standard_D2ds_v5 (General Purpose, 2 vCores, not Burstable), PostgreSQL 16, Premium_LRS storage

App framework: Django 4.2, psycopg2, CONN_MAX_AGE=60, CONN_HEALTH_CHECKS=True (already configured)

Symptom

Over a 2-day period we captured 6 occurrences of psycopg2.OperationalError / django.db.utils.OperationalError when the app tried to connect to our Flexible Server, causing HTTP 500 responses to end users:

2026-07-07T14:41:13Z  psycopg2.OperationalError: connection to server at "myapp-pgserver.postgres.database.azure.com" (10.x.x.x), port 5432 failed: timeout expired
2026-07-07T15:17:29Z  same, "timeout expired"
2026-07-08T04:24:18Z  "timeout expired" → 30s later, "Connection refused"
2026-07-08T09:17:13Z  "timeout expired"
2026-07-08T12:02:39Z  "timeout expired"
2026-07-08T12:58:35Z  "timeout expired"

Each occurrence was observed simultaneously across multiple App Service instances, ruling out a single-instance-local issue.

What we've already confirmed and ruled out

CPU/Memory on the DB server: normal at every failure timestamp (single digits to ~20% CPU, ~44-55% memory) — not resource exhaustion.

active_connections: peaked around 100-120, max_connections=859 for this SKU — nowhere near the limit.

Not a Burstable-tier CPU-credit issue — confirmed General Purpose tier.

App Service side: HealthCheckStatus stayed at 100% throughout, zero Autoscale-triggered events, Auto Heal is disabled, App Service Plan CPU never exceeded ~32%. Yet InstanceCount briefly spiked from our steady 2 up to 3-4 in the same 5-minute windows as several of these DB failures, with no visible trigger for the spike.

One of the six is fully explained: the 2026-07-08T04:24 event falls exactly inside a Resource Health event on the DB server (Health Event Activated at 04:07:36Z, cause: PlatformInitiated, type: Downtime, with the detail message "The scheduled maintenance for your Azure Database for PostgreSQL - Flexible server is taking longer than expected", resolved at 04:30:04Z). We've since configured a custom maintenance window in a lower-traffic slot to reduce recurrence risk.

The other 5 occurrences have no corresponding Activity Log or Resource Health event at all — we pulled the full unfiltered Activity Log for the DB resource across the entire window and found nothing beyond the one maintenance event above. Automated backups run daily ~02:47-02:52 UTC and don't correlate with any of these timestamps either.

What we're trying to understand

Is there a known class of brief (seconds-to-~1 minute), platform-side connectivity blip on Flexible Server — e.g., at the private networking/VNet-integration layer — that wouldn't surface as a customer-visible Activity Log or Resource Health event?

Could the App Service InstanceCount fluctuation (2→3-4→2, no Autoscale/Auto-Heal/Health-Check trigger) be platform-initiated in a way that could itself cause a brief DB connectivity gap for the affected instances (e.g., new instances warming up and racing to connect)?

We don't currently have a support plan tier that includes a technical support ticket for this — are there recommended self-service diagnostics (beyond Resource Health/Activity Log/Metrics, which we've already exhausted) that could help pin down the remaining 5 occurrences?

Happy to share additional metrics/log excerpts if useful. Thanks in advance!

Environment

App Service: Linux, custom Docker container, App Service Plan P2v3, steady-state capacity = 2 instances

Database: Azure Database for PostgreSQL Flexible Server, SKU Standard_D2ds_v5 (General Purpose, 2 vCores, not Burstable), PostgreSQL 16, Premium_LRS storage

App framework: Django 4.2, psycopg2, CONN_MAX_AGE=60, CONN_HEALTH_CHECKS=True (already configured)

Symptom

Over a 2-day period we captured 6 occurrences of psycopg2.OperationalError / django.db.utils.OperationalError when the app tried to connect to our Flexible Server, causing HTTP 500 responses to end users:

2026-07-07T14:41:13Z  psycopg2.OperationalError: connection to server at "myapp-pgserver.postgres.database.azure.com" (10.x.x.x), port 5432 failed: timeout expired
2026-07-07T15:17:29Z  same, "timeout expired"
2026-07-08T04:24:18Z  "timeout expired" → 30s later, "Connection refused"
2026-07-08T09:17:13Z  "timeout expired"
2026-07-08T12:02:39Z  "timeout expired"
2026-07-08T12:58:35Z  "timeout expired"

Each occurrence was observed simultaneously across multiple App Service instances, ruling out a single-instance-local issue.

What we've already confirmed and ruled out

CPU/Memory on the DB server: normal at every failure timestamp (single digits to ~20% CPU, ~44-55% memory) — not resource exhaustion.

active_connections: peaked around 100-120, max_connections=859 for this SKU — nowhere near the limit.

Not a Burstable-tier CPU-credit issue — confirmed General Purpose tier.

App Service side: HealthCheckStatus stayed at 100% throughout, zero Autoscale-triggered events, Auto Heal is disabled, App Service Plan CPU never exceeded ~32%. Yet InstanceCount briefly spiked from our steady 2 up to 3-4 in the same 5-minute windows as several of these DB failures, with no visible trigger for the spike.

One of the six is fully explained: the 2026-07-08T04:24 event falls exactly inside a Resource Health event on the DB server (Health Event Activated at 04:07:36Z, cause: PlatformInitiated, type: Downtime, with the detail message "The scheduled maintenance for your Azure Database for PostgreSQL - Flexible server is taking longer than expected", resolved at 04:30:04Z). We've since configured a custom maintenance window in a lower-traffic slot to reduce recurrence risk.

The other 5 occurrences have no corresponding Activity Log or Resource Health event at all — we pulled the full unfiltered Activity Log for the DB resource across the entire window and found nothing beyond the one maintenance event above. Automated backups run daily ~02:47-02:52 UTC and don't correlate with any of these timestamps either.

What we're trying to understand

Is there a known class of brief (seconds-to-~1 minute), platform-side connectivity blip on Flexible Server — e.g., at the private networking/VNet-integration layer — that wouldn't surface as a customer-visible Activity Log or Resource Health event?

Could the App Service InstanceCount fluctuation (2→3-4→2, no Autoscale/Auto-Heal/Health-Check trigger) be platform-initiated in a way that could itself cause a brief DB connectivity gap for the affected instances (e.g., new instances warming up and racing to connect)?

We don't currently have a support plan tier that includes a technical support ticket for this — are there recommended self-service diagnostics (beyond Resource Health/Activity Log/Metrics, which we've already exhausted) that could help pin down the remaining 5 occurrences?

Happy to share additional metrics/log excerpts if useful. Thanks in advance!