Azure Database for PostgreSQL: Read replica restarted unexpectedly — no customer-initiated operation

Question

Azure Database for PostgreSQL: Read replica restarted unexpectedly — no customer-initiated operation

VinceR-2832 0

Problem description

I am concerned about the unexpected restarts of my Azure Database for PostgreSQL flexible server read replica that occurred twice on September 30, 2026, between 09:33 and 09:47 UTC, without any action from my team. After these restarts, the replica briefly refused connections, and no explicit error messages were captured. I am seeking to understand the cause of these restarts and whether similar events might happen again.

Environment

Azure Database for PostgreSQL flexible server in East US 2, affected component: read replica, environment details such as region, PostgreSQL version, compute tier, storage configuration, networking mode, and high availability configuration are not specified in the case information.

What I've already tried

I have verified that no one on my team initiated a restart, scale operation, or configuration change during the incident window. I reviewed the Azure Activity Log for relevant events and checked Resource Health, which showed the servers as available throughout. I examined the 'is_db_alive' metric, which dropped to zero during the connection refusal period. I also referred to self-help guidance, which explains brief connection refusals after restarts but does not identify the cause of the restarts or predict recurrence.

I've tried opening a Support Case but apparently I need to post this to a public forum before Microsoft Support will take action.

Current status

I am looking for an explanation of what caused the two unexpected restarts of the read replica on September 30, 2026, and whether I should expect similar events in the future. Any insights or additional diagnostics that can help determine the root cause would be appreciated.

Ganesh Chelluri 195 Reputation points Microsoft External Staff Moderator

2026-09-30T20:11:58.51+00:00
Hello @VinceR-2832 ,

Thank you for providing the UTC timestamp and confirming that no intentional restart or configuration change was performed.

Because the read replica recovered automatically within a few minutes and is currently healthy, please complete the following checks for the affected replica:

In the Azure portal, open Service Health → Health history and filter by the replica’s subscription, region, and the incident window beginning around 2026-10-01 01:00 UTC. Check whether the replica appears under Impacted resources.

Open the affected replica and navigate to Resource health → Health history. Review any health event covering the same interval and note the cause and status shown.

Open Activity log for the replica and filter to the same UTC interval. Check for restart, start, stop, update, scaling, deployment, configuration, or other administrative operations.

Confirm the replica is currently in Ready state and test connectivity to the replica endpoint.

Run the following validation queries against the replica:

SELECT 1;

SELECT pg_is_in_recovery();

The first query confirms database connectivity. The second confirms that the server is operating in recovery/read-replica mode.

In Azure Monitor → Metrics, review the following metrics across the incident window and the recovery period:

Database Is Alive

Max Physical Replication Lag or Read Replica Lag

Active Connections

Failed Connections

CPU

Memory

Storage utilization

Please confirm whether connectivity remained stable after recovery and whether replication lag returned to its normal level.

If the replica becomes unavailable again, remains outside the Ready state, accumulates replication lag, or fails the validation queries, capture the new UTC timestamp and the Resource Health event details so the recurring failure can be correlated precisely in private message.
VinceR-2832 0 Reputation points

2026-10-06T11:58:23.6533333+00:00

@Ganesh Chelluri There is nothing in the Health History (neither in Service Health, nor in Resource Health) about this outage. The replica recovered cleanly. I opened a support case because there's zero indication as to the cause.

1 answer

Your answer

VinceR-2832 0 Reputation points

2026-10-06T11:58:23.6533333+00:00

@Ganesh Chelluri There is nothing in the Health History (neither in Service Health, nor in Resource Health) about this outage. The replica recovered cleanly. I opened a support case because there's zero indication as to the cause.

Answer 1

The unexpected restart of the Azure Database for PostgreSQL Flexible Server read replica was most likely caused by a platform-initiated maintenance, failover, host recovery, or service healing event, not a customer action.

Recommendations:

Azure Resource Health and Service Health for maintenance or platform events during 09:33-09:47 UTC.
Activity Log for any Microsoft-initiated operations.
PostgreSQL logs around the restart time for messages such as:
database system was shut down
database system is ready to accept connections
Azure metrics (is_db_alive, connections, CPU, storage) to correlate the outage window.