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

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:

1. 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.
2. 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.
3. 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.
4. Confirm the replica is currently in Ready state and test connectivity to the replica endpoint.
5. 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.

1. 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.