PostgreSQL flexible server tombstoned — not in portal, still billed, DELETE returns 204

Question

We have an orphaned/tombstoned Azure Database for PostgreSQL flexible server.

Server: od-postgresql
RG: WebTeam
Subscription: 27a6aae6-ce60-4ae4-a06e-cfe9c1e824d4
Tags: AutoMigration=true (created 2024-09-14)

Symptoms:

• Not visible in portal or Resource Graph (az graph returns 0)
• az postgres flexible-server list still shows Ready, version 11
• ARM GET / stop → ResourceNotFound
• REST DELETE → 204, but server remains in list
• FQDN od-postgresql.postgres.database.azure.com still resolves; TCP 5432 open
• Cost Management: ~€58.67 in July on this resource ID
• Owner confirmed unused; workloads moved to od-postgresql-server-dev/prod months ago

Billing support case #2608030050003467 said Billing cannot force-delete and technical support requires a paid plan (we are on Basic).

Please can the PostgreSQL Flexible Server team perform a backend tombstone purge?

Correlation ID from DELETE: 23cf1b99-a56c-4930-9537-c2d7a5abade7

Answer 1

Thanks Allan — this matches what we see.

Full resource ID:

/subscriptions/27a6aae6-ce60-4ae4-a06e-cfe9c1e824d4/resourceGroups/WebTeam/providers/Microsoft.DBforPostgreSQL/flexibleServers/od-postgresql

Region: West Europe

DELETE correlation / request ID: 23cf1b99-a56c-4930-9537-c2d7a5abade7

(UTC ~2026-08-03T13:22:06Z from REST DELETE)

Billing case #2608030050003467 (Basic plan — Billing cannot force-delete).

Could a Microsoft moderator please escalate to the Azure Database for PostgreSQL product team for a backend tombstone purge and billing cleanup?

Answer 2

• A "tombstoned" server occurs when a delete operation is interrupted, leaving behind residual metadata (name reservations or subnet associations) that prevents full removal.

• Even if the server is not visible in the Azure Portal, these residual records can continue to incur charges.

• Standard deletion commands might return a 204 (No Content) success code because the resource provider no longer recognizes the server, even though Azure Resource Manager still holds the metadata.

• Resolution: This situation typically requires Azure Support to investigate the backend control plane and perform a manual cleanup of the stale metadata. [3, 5]

Please provide the Subscription ID and Resource ID to help you open an Azure Support request.

Answer 3

Hello @Sergio Carrasco

Based on the information you've provided, this appears to be an orphaned (tombstoned) Azure Database for PostgreSQL Flexible Server where the control plane and data plane are out of sync.

The key indicators are:

• The server is not visible in the Azure portal or Azure Resource Graph.
• ARM GET returns ResourceNotFound.
• DELETE returns 204 (No Content), but the resource continues to exist.
• az postgres flexible-server list still returns the server.
• The FQDN continues to resolve and accepts connections.
• Cost Management continues to report charges.

Under normal circumstances, a successful DELETE should eventually remove the resource from both the control plane and billing. The behavior you're seeing suggests the resource metadata has become inconsistent within the PostgreSQL resource provider.

Unfortunately, there isn't a supported customer-side method to remove a tombstoned resource in this state using Azure Portal, ARM, Azure CLI, PowerShell, or the REST API.

Since you've already confirmed:

• the workload has been migrated,
• the resource is no longer required,
• Billing Support has confirmed they cannot perform the deletion,

this requires investigation by the Azure Database for PostgreSQL engineering team for a backend cleanup of the orphaned resource and any associated billing records.

In addition to the Correlation ID you've already provided, it would be helpful to include:

• The full resource ID (if available)
• Subscription ID
• Region
• UTC timestamps of the DELETE requests
• Any x-ms-request-id or x-ms-correlation-request-id response headers from the REST API

Those identifiers will help the engineering team trace the backend operation and determine why the resource provider still returns the server while ARM reports it as missing.

Given that Billing Support has already confirmed they cannot resolve this and the resource is in an inconsistent state, a Microsoft moderator may be able to help escalate this thread to the Azure Database for PostgreSQL product team for a backend cleanup, especially since the orphaned resource continues to incur charges.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.