Azure Managed Redis not allowing control plane operations after starting maintenance >1week ago

Question

Azure Managed Redis not allowing control plane operations after starting maintenance >1week ago

Robert Simons 20 Microsoft Employee

Background:

We have an Azure Managed Redis. Its server status is currently: Running - Balanced B1. Its Database status is currently: Running. We also have two private endpoints configured for it. Their provisioning states are both: Succeeded and the Connection Status states are both: Approved. Our resources are actively using the Redis cache with no issues.

One week ago, in the Activity Log for the Managed Redis resource there is an event for "Health Event InProgress" with an event description: "Planned maintenance has started on this instance and your instances will undergo failover. For more information, see aka.ms/Redis/ARMPatching". There are no events in the Activity Log for it being completed.

Issue:

When we try to deploy to this Managed Redis (Bicep control plane operations) Ex]

Microsoft.Cache/redisEnterprise@2025-07-01

and

Microsoft.Cache/redisEnterprise/databases@2025-07-01

we get validation errors:

Error: Code=InvalidTemplateDeployment; Message=The template deployment '[REDACTED]' is not valid according to the validation procedure. The following resource provider(s) - 'Microsoft.Cache/redisEnterprise (2025-07-01)' reported preflight validation errors. Tracking id is '[REDACTED]'. See inner errors for details.
Error: Code=Conflict; Message=The cluster is not yet running.

This always worked before.

We also cannot deploy the private endpoints either. We get the error:

Status: Failed
Error: 
    Code: Conflict
    Message: Call to Microsoft.Cache/redisEnterprise failed. Error message: Cannot manage private endpoint connection while cache '[REDACTED]' is in 'Succeeded' state. Please wait for the cache to reach a stable state before retrying. CorrelationID=[REDACTED] RequestID=[REDACTED] Timestamp=[REDACTED]

This also always worked before. We suspect the planned maintenance is "stuck" and so even though the data plane is healthy and our services can actively use the Redis cache with no issues we cannot make any control plane operations for it.

Question:

How can we once again perform control plane operations on this Azure Managed Redis resource?

0 comments

Answer accepted by question author

Manoj Kumar Boyini 19,590 Microsoft External Staff Moderator

Hi @Robert Simons

We received an update from Engineer @Mitchell Lerdahl regarding this issue.

During the planned maintenance operation that started on May 26, the service attempted to provision replacement nodes to facilitate the failover process. However, due to regional capacity constraints, one of the required nodes could not be provisioned at that time.

As a result, the maintenance operation was unable to complete successfully and the resource remained in a patching state, which prevented control plane operations from proceeding as expected. Once sufficient capacity became available, the missing node was successfully provisioned on June 15, allowing the maintenance process to continue.

Please verify whether you are now able to perform the previously affected control plane operations. If you continue to encounter any issues, let us know and we'll be happy to assist further.

0 comments

1 additional answer

Your answer

Answer 1

Hello !

Thank you for posting on MS Learn Q&A.

Azure Managed Redis maintenance uses planned failover during Redis/VM patching and you can experience expected effects as brief connection interruptions, temporary CPU/memory increase and the cache remaining available with possible connection blips. A maintenance Activity Log healthevent is emitted when maintenance begins but I can say that control plane lock lasting more than a week is not normal expected behavior.

https://learn.microsoft.com/en-us/azure/redis/scheduled-maintenance

The important point is that data plane healthy does not mean ARM/control plane healthy. Your apps can keep using Redis while the Microsoft.Cache/redisEnterprise resource provider still considers the cluster not ready for management operations.

Try to run REST GETs against both the cluster and database and compare provisioningState and resourceState. The Redis Enterprise GET API exposes both fields and the database APIs also tell you to check provisioningState and resourceState for detailed status.

https://learn.microsoft.com/en-us/rest/api/redis/redisenterprisecache/redis-enterprise/get?view=rest-redis-redisenterprisecache-2025-07-01

SUB="<subscription-id>"
RG="<resource-group>"
CACHE="<redis-name>"
DB="default"
az rest --method get \
  --url "https://management.azure.com/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Cache/redisEnterprise/$CACHE?api-version=2025-07-01" \
  --query "{provisioningState:properties.provisioningState, resourceState:properties.resourceState, privateEndpoints:properties.privateEndpointConnections[].{name:name, provisioningState:properties.provisioningState, status:properties.privateLinkServiceConnectionState.status}}"
az rest --method get \
  --url "https://management.azure.com/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Cache/redisEnterprise/$CACHE/databases/$DB?api-version=2025-07-01" \
  --query "{provisioningState:properties.provisioningState, resourceState:properties.resourceState}"

also check the Activity Log for the Redis resource around the maintenance start time:

az monitor activity-log list \
  --resource-id "/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Cache/redisEnterprise/$CACHE" \
  --offset 14d \
  --query "[].{time:eventTimestamp, operation:operationName.value, status:status.value, subStatus:subStatus.value, correlationId:correlationId}"

Do not delete or recreate private endpoints or the Redis resource unless you are prepared for impact. Since the resource provider is returning Conflict before deployment, you may need to open an Azure support request.