An Azure service that provides access to a secure, dedicated Redis cache, managed by Microsoft.
Since it started at a fairly exact time (around 06:30 UTC on Oct 14) and some requests still succeed, I'd first rule out a maintenance or failover event on the cache, then look at load. Here's the order I'd go in:
- Open the cache in the portal and check Resource Health for anything logged around that time.
- Under Metrics, chart Errors and split by ErrorType. If you see Failover, the cache was patched or failed over. Connections from the node that went down move to the other node and can stay unbalanced. Restarting your client apps recreates and redistributes them, and that often clears the timeouts.
- Chart Server Load for the same window. Spikes near 100 that line up with the timeouts mean the server is too busy (long-running commands or too much traffic for the size).
SLOWLOG GETwill show any slow commands. - On the client side, check CPU (keep it under 80%) and Connected Clients. If you use StackExchange.Redis, look at the timeout exception: if
Busyis higher thanMinunder WORKER or IOCP, raise the thread pool minimums.
Paste the full timeout exception message here (with any host names or keys removed). It usually tells you which side is the bottleneck.
One more thing for planning: Azure Cache for Redis Basic, Standard and Premium retire on September 30, 2028, so if you end up resizing or rebuilding this cache, it's worth looking at Azure Managed Redis at the same time.
Which client library and tier are you using?
If this resolved your issue, please consider accepting it as the answer. If the metrics don't show anything unusual, let me know and I'll be happy to keep helping.
Reference: