The postgreSQL Flexi 17.9 Azure database is in inaccessible state. How to we change its state to ready?

Question

The postgreSQL Flexi 17.9 Azure database is in inaccessible state. How to we change its state to ready?

Gulavani, Amruta 40

Kindly help.

Thanks,

Amruta.

Smaran Thoomu 35,870 Reputation points Microsoft External Staff Moderator

2026-07-14T14:06:20.87+00:00
Hi Gulavani, Amruta

Could you please let us know if the PostgreSQL Flexible Server itself is showing as Inaccessible, or if you're referring to a specific database within the server?

Also, could you confirm:

When did you first notice the database entered this state?

Was there any recent activity, such as a maintenance event, scaling operation, restart, or version upgrade before this occurred?

Are you able to access the server from the Azure portal, or is it inaccessible there as well?

If you're comfortable sharing, please send us the following details via Private Message so we can take a closer look:

Subscription ID

Resource Group name

PostgreSQL Flexible Server name

Azure region

Approximate time (UTC) when the issue started

These details will help us determine whether this is a configuration issue or if the server requires further investigation from the backend.

Answer accepted by question author

Smaran Thoomu 35,870 Microsoft External Staff Moderator

Hi @Gulavani, Amruta

Thank you for your patience.

Based on the investigation, the PostgreSQL Flexible Server entered the Inaccessible state because the User Assigned Managed Identity (UAMI) associated with the server did not have the required permissions on the Azure Key Vault used by the server.

After granting the managed identity the following Key Vault permissions:

Get
Wrap Key
Unwrap Key
List (if applicable)

and allowing some time for the service to reconcile the configuration, the server successfully transitioned from Inaccessible to Ready and became accessible again.

Based on your SR# team has confirmed that the server returned to the Ready state and they were able to access the database successfully.

I hope this helps. If you have any further questions, please let us know, we'll be happy to assist.

If this answer helped resolve your issue, please consider clicking Accept Answer so it can help other community members facing a similar problem.

0 comments

1 additional answer

Your answer

Smaran Thoomu 35,870 Reputation points Microsoft External Staff Moderator

2026-07-14T14:06:20.87+00:00

Hi Gulavani, Amruta

Could you please let us know if the PostgreSQL Flexible Server itself is showing as Inaccessible, or if you're referring to a specific database within the server?

Also, could you confirm:

When did you first notice the database entered this state?

Was there any recent activity, such as a maintenance event, scaling operation, restart, or version upgrade before this occurred?

Are you able to access the server from the Azure portal, or is it inaccessible there as well?

If you're comfortable sharing, please send us the following details via Private Message so we can take a closer look:

Subscription ID

Resource Group name

PostgreSQL Flexible Server name

Azure region

Approximate time (UTC) when the issue started

These details will help us determine whether this is a configuration issue or if the server requires further investigation from the backend.

Answer 1

Hi Amruta, first confirm whether the Flexible Server resource is marked Inaccessible or only one database connection is failing, because a database itself cannot be switched to Ready from the portal. Check Resource Health, the Activity Log, recent maintenance/scaling events, and the server overview state. If the control plane still responds, review networking, DNS, firewall/private endpoint, and connection errors before restarting anything. If the server resource itself remains Inaccessible and there is no active operation you can safely complete or cancel, do not delete or recreate it; open an Azure Database for PostgreSQL support request with the server resource ID, region, UTC start time, and correlation IDs so the backend state can be inspected.