Orphaned Production PostgreSQL Server active and billing, but missing from ARM / Azure Resource Graph

Question

Orphaned Production PostgreSQL Server active and billing, but missing from ARM / Azure Resource Graph

Infotech Language 20

Issue Summary: Following Microsoft's managed migration, our database endpoint myservername.postgres.database.azure.com remains fully operational, serving production traffic, and generating daily billing charges.

However, the server resource is completely absent from the ARM control plane. We have verified this via Azure CLI across all subscriptions attached to our tenant ID:

az graph query -q "Resources | where name contains 'myserver name'" returns 0 records across all subscriptions.

az postgres flexible-server list returns no instances.

Requested Action: Please execute an ARM Backend Synchronization & Discovery Refresh for our tenant/subscription to re-bind the running host infotech1.postgres.database.azure.com back to our ARM control plane so we can manage, back up, and configure the resource.

Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-08-05T07:16:41.8033333+00:00
Hello @Infotech Language ,

Thank you for bringing this issue to our attention.

From your description, the PostgreSQL Flexible Server endpoint remains operational and continues serving production traffic, while the corresponding resource cannot be discovered through Azure Resource Manager (ARM), Azure Resource Graph, or PostgreSQL Flexible Server management APIs.

This scenario requires investigation of the resource metadata associated with your specific subscription and tenant.

To proceed with the investigation, please provide the following details via private message:
• Subscription ID
• Tenant ID
• PostgreSQL Flexible Server name
• Azure region
• Screenshot/output of:

Azure Portal showing the resource is not visible

Azure Resource Graph query returning zero results

az postgres flexible-server list output
• Confirmation that the database endpoint remains reachable and serving application traffic
• Approximate timestamp when the issue was first observed

Once these details are received, we can engage the appropriate support team to determine whether this is a control-plane metadata inconsistency, resource registration issue, or another subscription-specific condition requiring backend investigation.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-08-10T15:32:57.2833333+00:00

Hi @Infotech Language ,

An infrequent temporary desynchronization within the Azure Resource Manager (ARM) cache led to the portal presenting obsolete data, resulting in the resource <not being visible/still visible based on your scenario>. As an intermediary, ARM handles user requests from tools like the portal, CLI, or Terraform before relaying them to underlying resource providers (e.g., for PostgreSQL Flexible Servers). In this instance, the desynchronization prevented full cache updates, causing visibility gaps without affecting the resource itself. These inconsistencies often stem from short-lived platform disruptions, such as network fluctuations, elevated system loads, or synchronization timing conflicts in ARM's caching infrastructure.

A manual ARM cache synchronization (rehydration) was performed, restoring visibility of the resources in the Azure Portal. The issue was mitigated without data loss or service interruption. Thank you for your patience. We apologize for any inconvenience and appreciate your partnership in resolving this.

Answer accepted by question author

Smaran Thoomu 255 Microsoft External Staff Moderator

Hi @Infotech Language
The required backend synchronization has now been completed, and the PostgreSQL Flexible Server infotech1 is visible again in the Azure Portal.

The server remained operational and continued serving application traffic during the visibility issue, and no data loss was observed.

Please verify from your side that the resource is now also discoverable through Azure Resource Graph/CLI.

Since you have confirmed that the resource is visible and the issue is resolved, we will proceed with closing the case.

Thank you for your patience and cooperation.

If the resolution has addressed your concern, please consider marking the response as the Accepted answer here. This will also help other customers who may encounter a similar issue.

0 comments

1 additional answer

Your answer

Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-08-05T07:16:41.8033333+00:00

Hello @Infotech Language ,

Thank you for bringing this issue to our attention.

From your description, the PostgreSQL Flexible Server endpoint remains operational and continues serving production traffic, while the corresponding resource cannot be discovered through Azure Resource Manager (ARM), Azure Resource Graph, or PostgreSQL Flexible Server management APIs.

This scenario requires investigation of the resource metadata associated with your specific subscription and tenant.

To proceed with the investigation, please provide the following details via private message:
• Subscription ID
• Tenant ID
• PostgreSQL Flexible Server name
• Azure region
• Screenshot/output of:

Azure Portal showing the resource is not visible

Azure Resource Graph query returning zero results

az postgres flexible-server list output
• Confirmation that the database endpoint remains reachable and serving application traffic
• Approximate timestamp when the issue was first observed

Once these details are received, we can engage the appropriate support team to determine whether this is a control-plane metadata inconsistency, resource registration issue, or another subscription-specific condition requiring backend investigation.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-08-10T15:32:57.2833333+00:00

Hi @Infotech Language ,

An infrequent temporary desynchronization within the Azure Resource Manager (ARM) cache led to the portal presenting obsolete data, resulting in the resource <not being visible/still visible based on your scenario>. As an intermediary, ARM handles user requests from tools like the portal, CLI, or Terraform before relaying them to underlying resource providers (e.g., for PostgreSQL Flexible Servers). In this instance, the desynchronization prevented full cache updates, causing visibility gaps without affecting the resource itself. These inconsistencies often stem from short-lived platform disruptions, such as network fluctuations, elevated system loads, or synchronization timing conflicts in ARM's caching infrastructure.

A manual ARM cache synchronization (rehydration) was performed, restoring visibility of the resources in the Azure Portal. The issue was mitigated without data loss or service interruption. Thank you for your patience. We apologize for any inconvenience and appreciate your partnership in resolving this.

Answer 1

Hi ,

Thanks for reaching out to Microsoft Q&A.

Based on the information provided, the PostgreSQL server appears to be reachable and actively serving production workloads, while the corresponding resource cannot be located through azure resource graph/azure CLI discovery. This suggests a possible discrepancy between the resource's operational state and its visibility in the Azure management plane.

Before escalating, I recommend verifying the following:

Confirm that you are querying all subscriptions and the correct azure tenant.
Check whether the server was migrated between resource groups, subscriptions, or deployment models during the managed migration process.
Review Azure Activity Logs and any migration related communications for indications of resource movement or reprovisioning.

If the server remains operational and billing continues, but the resource is not discoverable through Azure Portal, Azure resource graph/azure CLI, this situation will likely require investigation by Microsoft Support because customers do not have access to the backend resource-provider metadata that controls ARM visibility.

When opening a support request, include:

Fully qualified server name (for example, myservername.postgres.database.azure.com)
Subscription ID(s)
Tenant ID
Resource name (if known)
Evidence that the server is currently accessible
Recent billing records showing active charges
Results from the Azure CLI and Azure Resource Graph queries you have already performed

I would recommend creating a Severity A support case if the missing management-plane visibility is impacting your ability to administer, back up, secure, or otherwise manage the production database. Microsoft Support can investigate the resource-provider state and determine whether backend remediation or resource re-association is required.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Infotech Language 20 Reputation points

2026-08-05T23:25:35.41+00:00

The server is reachable but the ticket severity cannot be changed from C to A.
Sreetheja Adusumilli 965 Reputation points Microsoft External Staff Moderator

2026-08-06T02:27:08.49+00:00

Hello @Infotech Language ,

We sincerely apologize to hear that the issue has not yet been resolved. Your satisfaction is important to us, and we are committed to working with you toward a resolution. Please share your email ID, feasible time to connect in Private Message.
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-08-13T06:13:17.9233333+00:00

Hi @Infotech Language ,

We haven’t received a response. Please let us know if you need any additional information or assistance from my side.