Azure Database for PostgreSQL flexible server: Diagnostic log export to Log Analytics stopped suddenly for all categories, server healthy, recreating settings and restart have no effect

Question

Issue

Diagnostic log export from an Azure Database for PostgreSQL flexible server (West Europe) to a Log Analytics workspace stopped abruptly on 24 Aug 2026 between 08:43–08:57 UTC. All five resource-specific tables ceased ingesting new records simultaneously:

Table	Last record (UTC)
PGSQLPgBouncer	08:57:26
PGSQLServerLogs	08:57:22
PGSQLQueryStoreRuntime	08:49:44
PGSQLAutovacuumStats	08:48:41
PGSQLPgStatActivitySessions	08:43:39

The database itself is fully healthy: status Available, ~645 succeeded connections/hour, 0 failed connections, normal CPU/memory/storage/IO. log_connections=ON, so server log volume is guaranteed — the logs are being generated but never arrive.

Environment

• Azure Database for PostgreSQL flexible server, West Europe
• Destination: Log Analytics workspace (same region), resource-specific destination table
• Diagnostic setting: category group "audit" (all PG categories), unchanged for months and working until 24 Aug 08:57 UTC
• Workspace: Pay-as-you-go, daily cap disabled, well under any ingestion limits (~20 MB/day)

Troubleshooting already performed (all without effect)

1. Verified no Service Health incidents, no relevant Activity Log operations at failure time (no config, network, or deployment changes)
2. Re-saved the existing diagnostic setting
3. Deleted and recreated the diagnostic setting
4. Created a second diagnostic setting exporting PostgreSQL Server Logs to a storage account in the same region — after 2+ hours, no insights-logs-* container was ever created, so the export is dead at the source regardless of destination
5. Restarted the server — PostgreSQL startup log entries never arrived in the workspace
6. Queried the workspace _LogOperation table — zero operational events (no throttling, no quota, no errors); the workspace never received the data

Per the diagnostic settings documentation, data should flow within 90 minutes of creating a setting, and if disable/re-enable does not resolve it the issue is in the underlying routing mechanism. Everything points to the platform-side diagnostic export/routing pipeline for this specific resource being broken.

Questions

1. Is there any customer-visible way to see or reset the state of the diagnostic export pipeline for a flexible server?
2. Does a compute scale operation (which redeploys to new underlying compute) reinitialize the export agent, and is that a recommended mitigation?
3. Can Microsoft restore the export from the backend, and are the logs generated since 08:57 UTC recoverable, or is the gap permanent?

Answer 1

Hello @megamingus

Given the results of your previous tests, particularly the fact that both the Log Analytics and the separate Storage Account destination have stopped receiving the logs, I agree that this should now be investigated by Microsoft Support.

To answer your questions directly:

1. Is there a method available for checking or resetting the diagnostic export pipeline?

Nothing can be done from the customer's side apart from managing or recreating the diagnostic settings and destinations. There is no documented procedure to restart the underlying PostgreSQL/Azure Monitor diagnostic export pipeline; since recreating the diagnostic setting had no effect, Microsoft Support would need to investigate the backend state.

2. Would increasing the size of the PostgreSQL server cause the pipeline to recover?

It may be a side effect of moving or reconfiguring the underlying computing resources, but this is not a documented or guaranteed way to fix the problem by exporting diagnostic logs. There's no point in scaling the production server for this, especially before Support has had a chance to review the current failure state.

3. Can Microsoft fix the diagnostic pipeline?

If the issue lies with the service-side export pipeline, Microsoft would need to investigate and fix it. The test you ran using your Storage Account is useful evidence, as it indicates the problem occurs before the destination and not specifically with Log Analytics.

4. Is it possible to recover the missing logs since about 08:57 UTC?

It would be incorrect to assume they can be replayed. Diagnostic settings stream the logs to the specified destination and are not meant to function as a separate store from which customers can access the data. Nevertheless, you should look at the PostgreSQL Flexible Server → Monitoring → Server logs right away. If server logging was enabled and the relevant files are still within the retention period, you may be able to retrieve some PostgreSQL logs without relying on the Azure Monitor diagnostic export.

Then open the support case and provide Microsoft with the server resource ID, the West Europe region, the failure timestamp (between 08:43 and 08:57 UTC), the diagnostic-setting configuration, and the results of both the Log Analytics and Storage Account tests.

You should also put off any further disruptive changes, such as scaling or redeployment, until Support has taken control of the backend state.

Microsoft documentation on PostgreSQL Flexible Server logging and diagnostic settings:

Configure and access logs for PostgreSQL Flexible Server

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.