Fix Azure Cache for Redis Errors & Migrate to Azure Managed Redis

Before you change anything, you need to know what's actually broken. Guessing costs time. Azure Monitor has Azure Cache for Redis-specific metrics that show you exactly what's happening.

In the Azure portal, open your cache resource and click Metrics in the left menu under "Monitoring." Add the following metrics to a single chart:

• Connected Clients, how many clients are currently connected
• Cache Misses, requests that didn't find a key in cache
• Server Load, percentage of time the Redis server is processing requests
• Used Memory, current memory usage

Set the time range to the last 24 hours and look for spikes in Server Load or Connected Clients that correlate with the time your errors started. A Server Load consistently above 80% is a red flag, Redis is single-threaded for command processing, so sustained high server load means your application is overwhelming the cache with requests.

You can also pull these diagnostics via the Azure CLI if you prefer working in a terminal. Replace the placeholders with your actual resource group and cache name:

az monitor metrics list \
  --resource /subscriptions/{sub-id}/resourceGroups/{rg-name}/providers/Microsoft.Cache/Redis/{cache-name} \
  --metric "connectedclients,usedmemory,serverLoad" \
  --interval PT1M \
  --output table

If you see Server Load above 80% for more than a few minutes at a time, that confirms you need to scale up or optimize your command patterns. If Used Memory is consistently near the max, your eviction policy needs attention (covered in Step 2). If Connected Clients is plateauing at exactly your tier's limit, that's the maxclients ceiling being hit.

When this step works, you'll have a clear picture of which specific metric is the root cause, not a vague "it's slow." That context makes every subsequent fix step faster and more confident.

One of the most common Azure Cache for Redis configuration mistakes I see is leaving the maxmemory-policy at its default or setting it to something that made sense at launch but doesn't match how the application actually uses the cache under real load. When Redis runs out of memory and there's no clear eviction strategy, it either throws errors or starts evicting keys your application didn't expect to lose.

The default policy for most Azure Cache for Redis tiers is volatile-lru, which only evicts keys that have an expiry set. If your application stores a lot of keys without expiry, volatile-lru does nothing and Redis returns an OOM (out of memory) error instead.

To check your current policy, open the Azure portal → your cache resource → Advanced settings in the left menu. You'll see a maxmemory-policy dropdown. Common options and when to use each:

• allkeys-lru, evicts the least recently used key across all keys, regardless of expiry. Best for general caching workloads.
• volatile-lru, only evicts keys with expiry set. Good when you have a mix of session data (with TTL) and permanent reference data you never want evicted.
• allkeys-lfu, evicts least frequently used keys. Better than LRU when access patterns are highly skewed.
• noeviction, never evicts, returns errors on write when memory is full. Only use this if your application explicitly handles OOM errors and you want full control.

You can also set this via Azure CLI to make it repeatable and scriptable across environments:

az redis update \
  --name {cache-name} \
  --resource-group {rg-name} \
  --set "redisConfiguration.maxmemory-policy=allkeys-lru"

After saving, go back to the Azure portal Console and run CONFIG GET maxmemory-policy to confirm the change took effect. You should see the new policy reflected immediately without a cache restart.

If your application is .NET and you're seeing StackExchange.Redis.RedisTimeoutException: Timeout performing GET (5000ms), or similar, in your application logs, the problem is almost never actually Azure Cache for Redis itself. I know that sounds counterintuitive, but hear me out.

The most common cause of this error is .NET thread pool starvation. When your application is under load, the .NET thread pool can't keep up with the number of async operations, and StackExchange.Redis's async calls time out waiting for a thread to complete them. The cache is fine. Your app is choking.

First, check your application logs for this pattern alongside the timeout: look for high ThreadPool.QueueLength values or messages like "IOCP: (Busy=X, Free=Y, Min=Z, Max=W)". If Busy is close to Max, that's thread pool starvation.

The fix is to configure minimum thread pool sizes in your application startup. In your Program.cs or Startup.cs:

// Add this early in your startup code
ThreadPool.SetMinThreads(200, 200);

For the StackExchange.Redis connection itself, make sure you're using a singleton connection multiplexer, not creating a new connection per request. A new ConnectionMultiplexer per request is one of the most destructive patterns I see in Azure Redis implementations:

// WRONG, do not do this
var redis = ConnectionMultiplexer.Connect(connectionString);
var db = redis.GetDatabase();

// RIGHT, singleton, created once at startup
private static readonly Lazy<ConnectionMultiplexer> _lazyConnection =
  new Lazy<ConnectionMultiplexer>(() =>
    ConnectionMultiplexer.Connect(connectionString));

public static ConnectionMultiplexer Connection => _lazyConnection.Value;

Also set connectTimeout=5000 and syncTimeout=5000 in your connection string, and add abortConnect=false so the client retries on startup rather than crashing immediately if the cache isn't ready. If the error persists after these changes, the issue may be a genuine network latency spike, check the Cache Latency metric in Azure Monitor at the time of the timeouts.

This is the most important step in this guide right now, given where we are in the Azure Cache for Redis retirement timeline. If you're still running on any Azure Cache for Redis tier, Basic, Standard, Premium, Enterprise, or Enterprise Flash, you need a migration plan. The good news is Azure provides tooling to make this less painful than it sounds.

Azure Managed Redis reached General Availability in May 2025. It's the successor product, built on a more modern architecture. The migration path varies by which tier you're currently on.

For Enterprise and Enterprise Flash tiers, Microsoft will auto-migrate remaining caches by March 31, 2027. But waiting for an auto-migration is risky, you lose control of the timing and could face a cutover during a high-traffic period. Do it on your own schedule instead.

For Basic, Standard, and Premium tiers, the deadline is softer but still real. Plan your migration before October 1, 2026 for existing customers.

To start a migration in the Azure portal, navigate to your existing cache resource and look for the Migration to Azure Managed Redis option in the left sidebar. If it's not there yet, you can initiate it via CLI:

az redis export \
  --name {cache-name} \
  --resource-group {rg-name} \
  --prefix {export-prefix} \
  --container {sas-url-to-storage-container}

Then create your new Azure Managed Redis instance and import the RDB file. Choose your target tier carefully, Azure Managed Redis offers Memory Optimized, Balanced, Compute Optimized, and Flash Optimized tiers. Note that all Flash Optimized tiers are still in Public Preview as of this writing. Tiers using over 120 GB of storage (like Memory Optimized M150 and above, Balanced B150 and above, and Compute Optimized X150 and above) are also still in Public Preview. For production workloads, stay on GA tiers until those reach full availability.

After migration, update your application connection strings to point to the new Azure Managed Redis endpoint. Then run your test suite and monitor the Cache Hits and Cache Misses metrics for the first 24 hours to verify your warm-up strategy is working correctly.

Since November 2024, when you create a new Standard or Premium tier Azure Cache for Redis cache, Azure automatically enables zone redundancy using Automatic_Zonal_Allocation in regions that support availability zones. That's a great default. But a lot of teams who migrated to Azure Managed Redis or scaled between tiers found that zone redundancy didn't carry over as expected, and they're now running without the HA protection they thought they had.

Here's how to verify your zone redundancy status. In the Azure portal, go to your cache resource → Overview. Look for the "Availability Zones" field in the properties panel. If it shows "Not configured" or is blank, zone redundancy is off.

To check via CLI:

az redis show \
  --name {cache-name} \
  --resource-group {rg-name} \
  --query "zones" \
  --output tsv

If the output is empty, you're not zone-redundant. For Premium tier caches, you can choose availability zones explicitly during creation or update. For Standard tier, let Azure choose automatically. You cannot add zone redundancy to an existing non-redundant cache without recreating it, so this is something to verify before you consider a deployment complete, not after.

When creating a new Premium cache with explicit zone selection via CLI:

az redis create \
  --name {cache-name} \
  --resource-group {rg-name} \
  --location eastus \
  --sku Premium \
  --vm-size P1 \
  --zones 1 2 3

For Standard tier, use --zone-redundancy Enabled and let Azure handle zone assignment automatically. After creation, re-run the az redis show command above and confirm zones are listed in the output. If your region doesn't support availability zones, the command will succeed but the zones field will still be empty, that's expected, not a bug.