Azure Database for PostgreSQL: Stuck 'Dropping' state after delete — Root cause and resolution needed

Question

Problem description

I am experiencing an issue with an Azure Database for PostgreSQL flexible server in the East US region. The server became unavailable on 2026-10-30, and I submitted a delete request on 2026-11-02. Despite the delete being accepted, the server remains in the 'Dropping' state for over 40 hours, and subsequent GET/list operations still show it as 'Dropping'. A repeat delete request now returns 'ResourceNotFound', but the server is still visible in management tools. I want to understand the root cause of this behavior and how to resolve it to fully remove the server and make its name reusable.

Environment

Azure Database for PostgreSQL flexible server, Region: East US, the server was created as a restored/copied server from another flexible server.

What I've already tried

I attempted to restart the server after the outage, but it did not restore normal service. I also submitted a delete request, which was accepted, but the server remained in the 'Dropping' state for an extended period. I have not tried any other troubleshooting steps or diagnostics.

Current status

Currently, the server still appears in management results as 'Dropping', and a repeat delete returns 'ResourceNotFound'. I am seeking an explanation of the root cause and guidance on how to fully remove the server and prevent this issue in the future.

Answer 1

Update (2026-11-10): The stale Dropping record cleared on its own around 2026-11-07. GET/list no longer return it and the name is available again. So this is no longer about cleanup. What we need now is root cause and prevention.

Context the original post is missing:

• The server was a point-in-time restore of a production Flexible Server, East US. We restore a fresh copy weekly and delete the previous one.
• This is the 4th failure on these restored servers in about two months:
  1. Sep 2026: maintenance promoted a standby with an obsolete storage record. PITR from the source failed for 14 days until Microsoft applied a metadata fix on 2026-09-28.
     1. 2026-10-30: unplanned outage on the restored server; restart failed.
        1. 2026-11-02: delete accepted, stuck in Dropping ~4 days; a retried DELETE returned 404.
           1. 2026-11-09: a new PITR from the same source failed with InternalServerError after ~19 min (tracking ID 626c012a-6624-4f69-89fd-689a39e5b9e5). A retry on 2026-11-10 succeeded.

Questions:

1. Is stale Dropping metadata after delete a known defect, with a fix scheduled?
2. Could PITR restores from a source that had the September storage-record problem inherit something that causes these failures?
3. Is there a health signal we can alert on before a restored server becomes unrecoverable?
4. Any recommended pattern for weekly restore-and-replace that avoids this (restore settings, naming, delete method)?