Azure DocumentDB MongoDB vCore cluster stuck in UpdateFailed state for over a week - 409 Conflict on all operations

Hi Abhishek Shinde,
Thank you for providing detailed diagnostics and activity log information. Based on the information shared, the behavior you are experiencing is expected for this situation.

Azure Cosmos DB for MongoDB vCore clusters do not support version downgrades. The attempted downgrade from MongoDB 8.0 to 7.0 is an unsupported operation. Once such a request is initiated, the cluster can enter a permanent UpdateFailed and provisioningState Failed condition. In this state, the control plane holds an internal lock, and all subsequent ARM operations return HTTP 409 Conflict indicating that another operation is already in progress. This lock does not automatically clear, even after an extended waiting period, which explains why the cluster remains stuck after more than a week.

There is currently no supported way to force-cancel or clear a stuck in-progress operation for a MongoDB vCore cluster. Customer-initiated actions such as retries, tag updates, firewall rule changes, or configuration updates cannot resolve this condition once the cluster is in UpdateFailed status. Only internal service remediation is possible, and in this type of failure, in-place recovery is not supported.

Regarding data recovery, once the cluster enters this state, the data plane becomes unavailable. Since the gateway is unreachable and port 10260 connection attempts time out, tools such as mongosh and mongodump cannot connect. For Free tier MongoDB vCore clusters, there is no backend-supported path to extract or recover data once the data plane is offline. As a result, the data should be considered unrecoverable in this scenario.

A cluster that is permanently stuck in UpdateFailed status due to an unsupported operation cannot be restored back to a Succeeded state. The supported resolution is to delete the affected cluster and provision a new MongoDB vCore cluster with the appropriate MongoDB version selected at creation time. Version changes for vCore clusters are upgrade-only and cannot be reversed.

As next steps, we recommend deleting the affected cluster and creating a new one using a supported version. If the workload was production critical, you may raise an Azure Support request and include the subscription ID, resource ID, and the activity log entry that shows the downgrade attempt. While data recovery is not available for Free tier clusters, submitting a support request helps the product team track and prevent similar scenarios.

For future deployments, MongoDB version selection should be treated as a permanent choice. Version changes should always be validated in non-production environments, and external backups should be maintained for any critical data, especially when using Free tier offerings where platform recovery is not guaranteed.

We understand the inconvenience this causes and appreciate your understanding. Please let us know if you need guidance on recreating the cluster or on version planning best practices going forward.