Share via

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

Kacper Fertacz 20 Reputation points
2026-05-27T17:36:46.19+00:00

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. Screenshot 2026-05-27 at 10.35.36 PM
Azure Database for PostgreSQL

1 answer

Sort by: Most helpful
  1. AI answer

    2026-05-27T17:37:20.9+00:00
    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.
    1. 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.

    1. 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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.