Replica PostgreSQL Server Restarting Approximately Every 15 Hours Without Any Identifiable Cause

Mr. Shan 0 Reputation points
2026-10-21T11:30:08.7166667+00:00

Hello Team,

We are investigating an unusual issue in our Azure PostgreSQL environment and would appreciate any guidance from the community.

Our setup consists of a Primary PostgreSQL server and a Read Replica. The replica server is observed to be restarting approximately every 15 hours, while the primary server remains stable and does not experience any restarts.

Environment Details:

  • Azure Database for PostgreSQL
  • Single-node deployment
  • 32 vCores
  • 128 GiB RAM
  • 1024 GiB Storage
  • Current storage utilization is approximately 45%
  • Primary and Replica setup

Observations:

  • The replica restart is not tied to peak workload periods and can occur at any time of the day, including during non-peak hours when activity is minimal.
  • We have identified a recurring pattern of restarts occurring roughly every 15 hours; however, the exact timing varies.
  • PostgreSQL logs do not show any obvious indicators such as PANIC, FATAL, crash-related messages, out-of-memory errors, or shutdown requests before the restart.
  • CPU utilization remains normal with no significant spikes.
  • IOPS, storage usage, and other infrastructure metrics remain stable around the restart time.
  • Memory utilization does not show any unusual behavior.
  • No abnormal query workload, connection surge, or replication lag has been observed prior to the restart.
  • The primary server continues to operate normally throughout these events.
  • The logs only indicate that the replica instance has restarted and completed recovery, but they do not reveal what triggered the restart.

Despite reviewing PostgreSQL logs and Azure monitoring metrics, we have been unable to determine the root cause.

Could you please advise on the following?

  1. What additional logs or diagnostics should we review to identify the cause of these periodic replica restarts?
  2. Are there any Azure platform-level events that could cause a replica to restart without generating corresponding PostgreSQL error messages?
  3. Has anyone encountered similar behavior where only the replica restarts while the primary remains unaffected?
  4. Are there any Azure-specific monitoring tools, backend diagnostics, or hidden metrics that could help identify the root cause?
  5. Would Microsoft Support be able to access platform telemetry or infrastructure logs that are not exposed through PostgreSQL logs or Azure Activity Logs?

Any recommendations, troubleshooting steps, or similar experiences would be greatly appreciated.

Thank you in advance for your assistance.Hello Team,

We are investigating an unusual issue in our Azure PostgreSQL environment and would appreciate any guidance from the community.

Our setup consists of a Primary PostgreSQL server and a Read Replica. The replica server is observed to be restarting approximately every 15 hours, while the primary server remains stable and does not experience any restarts.

Environment Details:

  • Azure Database for PostgreSQL
  • Single-node deployment
  • 32 vCores
  • 128 GiB RAM
  • 1024 GiB Storage
  • Current storage utilization is approximately 45%
  • Primary and Replica setup

Observations:

  • The replica restart is not tied to peak workload periods and can occur at any time of the day, including during non-peak hours when activity is minimal.
  • We have identified a recurring pattern of restarts occurring roughly every 15 hours; however, the exact timing varies.
  • PostgreSQL logs do not show any obvious indicators such as PANIC, FATAL, crash-related messages, out-of-memory errors, or shutdown requests before the restart.
  • CPU utilization remains normal with no significant spikes.
  • IOPS, storage usage, and other infrastructure metrics remain stable around the restart time.
  • Memory utilization does not show any unusual behavior.
  • No abnormal query workload, connection surge, or replication lag has been observed prior to the restart.
  • The primary server continues to operate normally throughout these events.
  • The logs only indicate that the replica instance has restarted and completed recovery, but they do not reveal what triggered the restart.

Despite reviewing PostgreSQL logs and Azure monitoring metrics, we have been unable to determine the root cause.

Could you please advise on the following?

  1. What additional logs or diagnostics should we review to identify the cause of these periodic replica restarts?
  2. Are there any Azure platform-level events that could cause a replica to restart without generating corresponding PostgreSQL error messages?
  3. Has anyone encountered similar behavior where only the replica restarts while the primary remains unaffected?
  4. Are there any Azure-specific monitoring tools, backend diagnostics, or hidden metrics that could help identify the root cause?
  5. Would Microsoft Support be able to access platform telemetry or infrastructure logs that are not exposed through PostgreSQL logs or Azure Activity Logs?

Any recommendations, troubleshooting steps, or similar experiences would be greatly appreciated.

Thank you in advance for your assistance.

Azure Database for PostgreSQL
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-21T11:31:18.18+00:00

    The next decisive step is to correlate each replica restart timestamp with that replica’s Maintenance history, Resource Health history, and control-plane Activity Log; if none identifies the event, open a Microsoft support request with exact UTC timestamps because PostgreSQL logs cannot expose every host or service-platform failure.

    1. Check replica-specific platform events

    Perform these checks on the replica resource, not only on the primary:

    1. Replica → Settings → Maintenance → Maintenance history
      • Open each Tracking ID near a restart.
      • Record maintenance type, start/end time, status, and export the history to CSV.
      • Azure-initiated software deployments and minor-version upgrades can restart a server; maintenance history is the supported way to confirm whether maintenance coincided with the restart. ^1^ ^2^
    2. Replica → Help → Resource health → Health history
      • Inspect events immediately before and after every restart.
      • Resource Health can classify incidents as User initiated, Planned, or Unplanned. Unplanned platform causes can include host reboots, hardware faults, networking issues, or software faults. Portal history covers up to 30 days. ^3^ ^4^
    3. Service Health → Health advisories, Service issues, and Planned maintenance
      • Filter by the replica’s subscription and region.
      • Create a Service Health alert so future platform events are captured immediately.
    4. Review the replica’s Activity Log for configuration, start/restart, scaling, maintenance, and automation operations.
      • Filter by the precise UTC interval and inspect the initiator/caller.
      • A clean Activity Log does not exclude a short platform event: transitions to Unknown and some short health transitions are not recorded there. ^5^

    A restart approximately every 15 hours is not documented as a normal read-replica cycle. Maintenance is plausible only if the timestamps correlate with Maintenance history or Service Health; do not attribute the pattern to maintenance from periodicity alone.

    2. Capture a complete timeline for the next occurrence

    If diagnostic export was not already enabled, configure it now; it cannot recover telemetry from before enablement:

    1. Open Replica → Monitoring → Diagnostic settings → Add diagnostic setting.
    2. Send data to a Log Analytics workspace.
    3. Select:
      • PostgreSQL Server logs
      • PostgreSQL Sessions data
      • AllMetrics
      • Query Store categories if workload correlation is also required
    4. Prefer Resource specific destination tables and save. ^6^

    Query the replica’s server-log timeline around a known restart:

    let restart = datetime(2026-10-21T10:00:00Z);
PGSQLServerLogs
| where LogicalServerName == "replica-server-name"
| where TimeGenerated between (restart - 15m .. restart + 15m)
| project TimeGenerated, Severity, Message
| order by TimeGenerated asc

    Also graph Read Replica Lag on the replica and Max Physical Replication Lag on the primary. Restart and catch-up time should appear in replica lag, helping establish the exact incident boundaries even when no PostgreSQL crash message exists. ^7^

    Because CPU, memory, IOPS, storage, workload, and lag have already been reviewed without anomalies, repeating those checks is unlikely to identify the trigger. The useful new evidence is the cross-service timestamp correlation above.

    3. Escalate when no customer-visible event explains it

    Open Replica → Help + support / Support + troubleshooting → New support request, selecting Azure Database for PostgreSQL → Read Replicas or the closest availability/restart category.

    Provide:

    • Replica and primary resource IDs, regions, PostgreSQL versions, and compute tiers.
    • At least three restart timestamps in UTC, including start, recovery completion, and outage duration.
    • Maintenance-history CSV, Resource Health screenshots/export, Activity Log export, and the Log Analytics interval.
    • Confirmation that the primary remained available.
    • Confirmation that PostgreSQL logs contain recovery startup but no preceding PANIC, FATAL, OOM, or shutdown request.
    • Any correlation ID or tracking ID displayed by the portal.
    • A request to correlate the timestamps with host lifecycle, platform maintenance, node movement, storage/network faults, and service recovery telemetry.

    Azure documents infrastructure faults, networking issues, and software bugs as possible unplanned disruptions handled by service recovery. When customer-visible histories are empty, determining which platform event occurred requires Microsoft’s service-side investigation rather than another PostgreSQL setting change. ^2^

    These portal paths apply to Azure Database for PostgreSQL Flexible Server. If this is the retired Single Server deployment model rather than a single-node Flexible Server, state that explicitly in the support request because its maintenance and diagnostic interfaces differ.

    References

    1. Schedule maintenance in Azure Database for PostgreSQL flexible server
    2. Overview of business continuity in Azure Database for PostgreSQL flexible server
    3. Azure Resource Health FAQ
    4. Resource Health overview
    5. Azure Activity Log event schema
    6. Configure and access logs in Azure Database for PostgreSQL
    7. Read replicas in Azure Database for PostgreSQL flexible server
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.