Azure Database for PostgreSQL Flexible Server stuck in "Updating" state - Unable to modify Networking/Firewall settings

Question

Hi Azure Team and Community,

I am facing a persistent issue with my Azure Database for PostgreSQL Flexible Server.

Problem Description:

My PostgreSQL Flexible Server has been stuck in the "Updating" state for a long time. Because of this, I am completely unable to make any changes to the server, especially:

• Network settings
• Firewall rules
• Private endpoint / VNet integration
• Any other configuration options

When I go to the Networking tab in the Azure Portal, I see messages indicating that operations are disabled because the server is not in a Ready state.

Current Status:

• Server State: Updating (has been in this state for hours/days)
• All configuration options are greyed out or disabled
• No option to cancel the update operation is visible

Questions:

1. How long should a normal update process take on a Flexible Server?
2. Is there a way to force the server back to Ready state or cancel the stuck update?
3. What is the recommended way to resolve this issue?Hi Azure Team and Community, I am facing a persistent issue with my Azure Database for PostgreSQL Flexible Server.

   Problem Description:

   My PostgreSQL Flexible Server has been stuck in the "Updating" state for a long time. Because of this, I am completely unable to make any changes to the server, especially:
   • Network settings
   • Firewall rules
   • Private endpoint / VNet integration
   • Any other configuration options
   When I go to the Networking tab in the Azure Portal, I see messages indicating that operations are disabled because the server is not in a Ready state.

   Current Status:

   • Server State: Updating (has been in this state for hours/days)
   • All configuration options are greyed out or disabled
   • No option to cancel the update operation is visible

   Questions:

   1. How long should a normal update process take on a Flexible Server?
   2. Is there a way to force the server back to Ready state or cancel the stuck update?
   3. What is the recommended way to resolve this issue?
   Server Tier: Brustable Also there is not much load on server right mow coz its in dev environment. I would really appreciate any help or guidance from the Azure team on how to resolve this stuck state, as it's currently blocking important network configuration changes for my application.

Answer 1

Hi @Kacper Fertacz

A PostgreSQL Flexible Server typically completes update operations within a short duration (usually a few minutes). If the server remains in the “Updating” state for an extended period, it usually indicates a backend issue where the operation is stuck and blocking further changes.

In your case, this behavior aligns with situations where the underlying service components (containers running on the compute node) become unhealthy, which prevents the update workflow from completing successfully. Similar cases have shown that backend health issues (for example, VM agent or container health) can keep the server stuck in a non-ready state until recovery actions are performed.

To resolve this, the Product Group investigated and performed a recovery action by restarting the affected service containers. This has now brought the server back to a healthy state and unblocked the pending operation.

At the moment, there is no customer-side action to cancel or force-complete such stuck updates. These scenarios require backend intervention to restore the server to the Ready state.

Additionally, as part of ongoing improvements, the engineering team is continuously enhancing automated detection and recovery mechanisms to identify such conditions earlier and minimize impact on customers.

We sincerely apologize for the inconvenience caused and appreciate your patience.

Answer 2

1. Normal update duration

For Azure Database for PostgreSQL flexible server, platform-driven operations such as scaling, maintenance, or networking changes typically cause a brief Updating state. Transient connectivity interruptions are usually under 60 seconds, though some events (for example, large transaction recovery) can occasionally take longer. Remaining in Updating for hours or days is not expected and indicates an issue that requires support intervention.

Relevant guidance:

• Transient connectivity interruptions should be short and automatically mitigated.
• If issues persist beyond about a minute or recur frequently, a support request is recommended.

2. Forcing the server back to Ready / cancelling the update

The platform does not expose any supported way to:

• Force a flexible server from Updating back to Ready, or
• Cancel an in-progress platform update/operation from the portal or CLI.

When the server is in Updating:

• Many management operations (including networking and firewall changes) are blocked until the state returns to Ready.
• If public access is disabled or networking is being changed, connectivity may be unavailable until the operation completes and networking is reconfigured.

Because there is no supported “force reset” for a stuck Updating state, the only safe resolution path is via Microsoft support.

3. Recommended steps to resolve the issue

Follow these steps end-to-end:

1. Check for service issues/outages
   • Go to the Microsoft Azure Service Dashboard and verify whether there are any known incidents affecting Azure Database for PostgreSQL in the region where the server is deployed.
2. Confirm whether a networking change is in progress
   • If a recent operation such as disabling public access, enabling/disabling public access, or migrating networking was initiated, the server will show Updating until that completes.
   • For example, disabling public access via the portal explicitly sets the server to Updating and then back to Ready when done. If it never returns to Ready, the operation is stuck.
3. Avoid further configuration changes until the state is resolved
   • While the server is Updating, networking and firewall changes are not applied and may be discarded (for example, firewall rules when public access is disabled). Wait for the state to be corrected before attempting further modifications.
4. Open an Azure support request
   • Because a multi-hour/days-long Updating state is not normal and there is no self-service cancel, open a support ticket so the service team can:
     • Inspect and clear any stuck internal operation on the server.
     • Restore the server state to Ready or advise on recovery options.
   • The PostgreSQL connectivity troubleshooting guidance explicitly recommends filing a support request when connectivity or platform issues persist beyond about 60 seconds or occur multiple times in a day.
5. After the server returns to Ready
   • Reconfigure networking as needed:
     • If using Public access (allowed IP addresses), re-add firewall rules and verify port 5432 is open from client networks.
     • If using private endpoints, ensure private endpoints and DNS are correctly configured.
   • If any networking migration (for example, VNet to private endpoint capable configuration) was involved, update infrastructure-as-code (such as Terraform) to match the new networking model and avoid reintroducing unsupported settings.

Because this is a dev environment with low load, there is no special tuning required on the compute tier (Burstable vs General Purpose) for this specific issue; the key is clearing the stuck platform operation via Azure support.

---

References:

• Troubleshoot connection issues to Azure Database for PostgreSQL
• Networking
• Disable public access
• Quickstart: Create an Azure Database for PostgreSQL flexible server
• Networking overview for Azure Database for PostgreSQL with public access (allowed IP addresses)
• Migrate from VNet to a Private Endpoint Capable Network Configuration (Preview)