PostgreSQL Flexible Server (West Europe): PostgreSQLLogs stopped reaching Log Analytics on 2026-08-24 on two servers; restart and diagnostic setting recreation do not help

Question

PostgreSQL Flexible Server (West Europe): PostgreSQLLogs stopped reaching Log Analytics on 2026-08-24 on two servers; restart and diagnostic setting recreation do not help

Hugo Lorenzo Mato 0

Two Azure Database for PostgreSQL Flexible Servers (PostgreSQL 18.4, West Europe, different subscriptions and different Log Analytics workspaces) stopped delivering the PostgreSQLLogs diagnostic category to Log Analytics on the same day, 2026-08-24, roughly two hours apart. Nothing changed on our side. A third server in France Central keeps delivering normally.

Symptoms

Server A (production): last PostgreSQLLogs row in AzureDiagnostics at 2026-08-24 06:14:06 UTC. Before that, 80,000-100,000 rows/day for weeks. Zero rows since.
Server B (dev): last row at 2026-08-24 08:25:59 UTC. Zero rows since.
Server C (France Central, same tenant): still delivering ~60,000 rows/day today.
The diagnostic settings on both servers are intact: category PostgreSQLLogs enabled, destination type AzureDiagnostics, workspace unchanged. The workspaces are healthy and still ingest other data types (AzureMetrics, AzureActivity).
No resource-specific tables (PGSQLServerLogs) receive anything either, and no other workspace in the subscriptions receives these logs.
Server logging parameters are at their system defaults: log_connections=on, log_disconnections=on, log_min_messages=warning, log_destination=stderr. logging_collector is off, read-only, system-default, identical on the server that still works.

What we verified

Both engines are healthy: is_db_alive=1 every minute across the cut-over window, stable active_connections, no restart, no shutdown/FATAL in the last rows received.
Activity log: no control-plane operation on either server between 2026-08-17 and 2026-09-04 (no configurations/write, no servers/write, no restart, no upgrade). The major version upgrade to 18 happened on 2026-08-05, and logs kept flowing for 19 days after it.
No Resource Health or Service Health events.
Server B (logfiles.download_enable=on) still produces hourly downloadable server log files (~850 KB each), so the engine is writing to stderr and the capture works; only the forwarding to Azure Monitor is dead. Server A returns zero downloadable log files despite the same setting.

What we tried (on the dev server)

az postgres flexible-server restart on 2026-09-07 02:36 UTC: back to Ready in one minute, still zero rows 24 minutes later.
Deleted and re-created the diagnostic setting with the exact same body on 2026-09-07 13:07 UTC: still zero rows 24 minutes later.

Questions

Is there a known issue with the PostgreSQL Flexible Server log forwarding agent in West Europe starting around 2026-08-24 (for example tied to the August 2026 maintenance rollout)?
Is there any customer-side action that restarts or re-registers the log forwarding agent, other than an engine restart or re-creating the diagnostic setting?
Is the platform maintenance history queryable for a server? GET .../maintenances?api-version=2025-08-01 returns 404 for us.

The subscription only has the Basic support plan, so we cannot open a technical support request. Any pointer to an internal investigation path is appreciated.

0 comments

1 answer

Your answer

Answer 1

There is a very close precedent for this failure pattern. A recent thread titled "PostgreSQL Flexible Server metrics stopped collecting after January 1, 2026 (https://learn.microsoft.com/en-us/answers/questions/5706476/postgresql-flexible-server-metrics-stopped-collect )" described almost the same symptoms: telemetry stopped reaching Azure Monitor, the server itself stayed healthy, and diagnostic settings had already been recreated multiple times with no effect. The root cause in that case was a backend fluentd container responsible for forwarding telemetry off the server becoming unhealthy. Nothing was wrong on the customer side, and nothing the customer could do would fix it. A Microsoft engineer restarted the container from the backend, and forwarding was expected to resume within about an hour.

Your symptoms match that pattern closely. The engine is healthy, hourly log files are still being produced locally, diagnostic settings have not changed, restart and recreation did not help, and another server in a different region is unaffected. That is consistent with a forwarding sidecar problem on Microsoft’s side rather than anything wrong with the engine, the diagnostic setting, or the workspace.

Here are direct answers to your questions:

I cannot confirm a specific West Europe incident tied to your August 24 date or the August 2026 maintenance rollout. I do not have visibility into that. The precedent above shows that this exact failure mode has occurred before for Flexible Server, so it is reasonable to assume you are seeing the same class of issue even if it is a separate occurrence.
Based on that precedent, there does not appear to be a customer‑side fix beyond what you have already tried. The broken component sits on Microsoft’s side of the pipeline, and the resolution required backend action.
Your 404 is almost certainly caused by the endpoint you used. The documented operation to list maintenance or update history for a specific resource is:

GET https://management.azure.com/{resourceId}/providers/Microsoft.Maintenance/updates?api-version=2023-09-01-preview

There is no “maintenances” operation in the published Microsoft.Maintenance API, and 2025‑08‑01 is not a published api‑version for this provider. That combination would return 404 even if maintenance history exists. It is worth trying the corrected call. One note: this endpoint reports host, OS, and VM‑level maintenance items. It does not report internal telemetry‑forwarding components like the fluentd sidecar from the precedent case, so it may return an empty list even when forwarding is broken. It is still the correct thing to rule out.

Since your Basic support plan does not give you access to a technical support ticket, the precedent case is useful here in a practical way too. It was resolved through a Microsoft engineer responding directly on Microsoft Q&A, not through a paid support case. I recommend posting your subscription ID and server names, along with the exact UTC timestamps you have already isolated, and linking to the January thread. That information will allow investigation to move quickly and pointing to a known failure mode may help a moderator route this to the right team faster.

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.

Hugo Lorenzo Mato 0 Reputation points

2026-09-07T19:15:22.4466667+00:00

Thank you very much for taking the time to answer, and for pointing to the January thread. That precedent matches our situation closely: healthy engine, hourly log files still written locally, diagnostic settings recreated, and a forwarding component on the platform side that we cannot reach from the customer side.

I tried the corrected maintenance endpoint (Microsoft.Maintenance/updates, api-version 2023-09-01-preview) on both servers; it returns InvalidResource for Flexible Server, so there is nothing to rule out from that side either.

Regarding the subscription details: I will hold them for a Microsoft moderator. The Q&A guidelines ask not to post identifiers publicly, and the moderators' usual practice is to request them through the "Private message" option under the question. See https://learn.microsoft.com/en-us/answers/support/quality-question ("do not include Personally Identifiable Information... This is a public site") and https://learn.microsoft.com/en-us/answers/support/code-of-conduct ("a Microsoft employee can start a private conversation with you to help you protect your data").

So, to any Microsoft moderator reading this: the exact UTC timestamps of the cut-over for both West Europe servers are in the question above, and I will gladly send the subscription IDs, tenant ID and resource names by private message as soon as you ask. If the log-forwarding container can be checked and restarted from the backend, as in the January case, that would very likely resolve it.

Thanks again for the help.
SHOUMIK CHAKRAVARTY 575 Reputation points

2026-09-08T02:19:48.6+00:00

Thanks for testing that endpoint and confirming the InvalidResource result & that rules out the maintenance history.

Let's wait for a moderator to pick up this thread.