An Azure managed PostgreSQL database service for app development and deployment.
- 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.
- 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.
- Recommended steps to resolve the issue
Follow these steps end-to-end:
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- Reconfigure networking as needed:
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)