Redis caches holding no clients and serving no operations
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1338 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | redis_idle.go |
Where it applies
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
az monitor metrics list \ --resource "$(az redis show -n <cache> -g <rg> --query id -o tsv)" \ --metric connectedclients operationsPerSecond \ --interval PT1H --offset 30d --aggregation Average MaximumThe 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.