# Azure Redis Cache Idle > A cache client can hold a connection open while issuing zero commands, so ZopNight requires both connectedclients and operationsPerSecond to sit below 1 (average and maximum) across 30 days of coverage before flagging an Azure Cache for Redis instance. The tier fee bills hourly regardless of use. Source: https://zop.dev/integrations/azure/recommendations/azure-redis-cache-idle Updated: 2026-08-19 --- ## An open connection is not a workload Redis clients routinely hold idle connections from forgotten config, connection pools, or a staging app nobody turned off. Conversely, real traffic can ride short-lived connections the client gauge barely registers. Neither axis alone can be trusted, which is why this rule reads two series, `connectedclients` and `operationsPerSecond`, and requires both to sit below their floors before an Azure Cache for Redis instance is called idle. Any hour at or above a floor on either axis, including one Maximum spike from a bursty consumer, ends the evaluation. ## Floors of 1 client and 1 op per second Caches register housekeeping noise from health probes, the monitoring agent, and keyspace notifications, so exact-zero gates would spare genuinely dead caches forever. The floors sit at 1.0 on both axes: above the platform baseline, below the faintest real workload. Coverage must reach 30 days on both series, so a cache created last week can never be flagged while its history is still forming. ## What deleting recovers Azure Cache for Redis bills its tier hourly: a C1 Standard costs the same serving zero commands as a hot session store. ZopNight prices the finding at the full tier run-rate, and when a smaller SKU exists in the same tier the recommendation also names the downsizing alternative for caches you would rather shrink than remove. ## Confirm the silence yourself ```bash az monitor metrics list \ --resource "$(az redis show -n -g --query id -o tsv)" \ --metric connectedclients operationsPerSecond \ --interval PT1H --offset 30d --aggregation Average Maximum ``` ## The abstain conditions Either series missing, under 30 days of coverage on either axis, any client or operation activity at the floor or above, or an unpriced tier cost: any one of them suppresses the finding. There is no tag path at all: a customer label can never gate deleting a data store. ## Deleting without regret Redis contents are by definition reconstructable, but check first for teams misusing the cache as a primary store; scan for keys without TTLs before deleting. Export anything surprising, then remove the cache and its private endpoints. Reader and Monitoring Reader cover the whole detection path.